LinuxLists.cc - [BK PATCH] klibc for 2.5.64

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi,

On Thu, 6 Mar 2003, Greg KH wrote:

> Here's a series of changesets that add klibc support to the 2.5.64
> kernel. The only change since the last time I sent this is an addition
> of a LICENSE file to the klibc directory, and a merge with your latest
> bk tree.

Ok, nobody wants to mention it, so I'll have to do it.
Above license is the BSD license. What were the exact reasons to choose
this one?

bye, Roman

2003-03-07 00:54:48

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Roman Zippel wrote:
> Hi,
>
> On Thu, 6 Mar 2003, Greg KH wrote:
>
>>Here's a series of changesets that add klibc support to the 2.5.64
>>kernel. The only change since the last time I sent this is an addition
>>of a LICENSE file to the klibc directory, and a merge with your latest
>>bk tree.
>
> Ok, nobody wants to mention it, so I'll have to do it.
> Above license is the BSD license. What were the exact reasons to choose
> this one?
>

Actually, it's the MIT license, which differs from the (new) BSD license
only in the no-endorsement clause, which seemed superfluous.

It was chosen because klibc is a non-dynamic library, and it would
otherwise be extremely awkward to link proprietary code against it if
someone would like to do so. Furthermore, I'm the author of most of the
code in there, and if someone really wants to rip it off it's not a huge
deal to me.

-hpa

2003-03-07 01:13:20

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi,

On Thu, 6 Mar 2003, H. Peter Anvin wrote:

> Actually, it's the MIT license, which differs from the (new) BSD license
> only in the no-endorsement clause, which seemed superfluous.
>
> It was chosen because klibc is a non-dynamic library, and it would
> otherwise be extremely awkward to link proprietary code against it if
> someone would like to do so.

Why would it be awkward? libgcc has the same problem, so they added this
paragraph:

In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file. (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine
executable.)

Why can't we do something similiar?

> Furthermore, I'm the author of most of the
> code in there, and if someone really wants to rip it off it's not a huge
> deal to me.

If it becomes part of the kernel (and a core part, not just some driver),
it would be awkward to have a completely different license, so this should
not be done without a very good reason.

bye, Roman

2003-03-07 01:25:24

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Roman Zippel wrote:
>
> Why would it be awkward? libgcc has the same problem, so they added this
> paragraph:
>
> In addition to the permissions in the GNU General Public License, the
> Free Software Foundation gives you unlimited permission to link the
> compiled version of this file into combinations with other programs,
> and to distribute those combinations without any restriction coming
> from the use of this file. (The General Public License restrictions
> do apply in other respects; for example, they cover modification of
> the file, and distribution when not linked into a combine
> executable.)
>
> Why can't we do something similiar?
>

Why does it matter?

>
>> Furthermore, I'm the author of most of the
>>code in there, and if someone really wants to rip it off it's not a huge
>>deal to me.
>
> If it becomes part of the kernel (and a core part, not just some driver),
> it would be awkward to have a completely different license, so this should
> not be done without a very good reason.
>

Why is it awkward?

-hpa

2003-03-07 09:45:06

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi,

On Thu, 6 Mar 2003, H. Peter Anvin wrote:

> > Why would it be awkward? libgcc has the same problem, so they added this
> > paragraph:
> >
> > In addition to the permissions in the GNU General Public License, the
> > Free Software Foundation gives you unlimited permission to link the
> > compiled version of this file into combinations with other programs,
> > and to distribute those combinations without any restriction coming
> > from the use of this file. (The General Public License restrictions
> > do apply in other respects; for example, they cover modification of
> > the file, and distribution when not linked into a combine
> > executable.)
> >
> > Why can't we do something similiar?
>
> Why does it matter?

You are avoiding my question. If something goes into the kernel, the
kernel license would be the obvious choice. Granting additional rights or
using a dual license is a relatively small problem. But you must certainly
have a reason to choose a completely different license?

bye, Roman

2003-03-07 13:33:09

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Roman Zippel wrote:
>
> You are avoiding my question. If something goes into the kernel, the
> kernel license would be the obvious choice. Granting additional rights or
> using a dual license is a relatively small problem. But you must certainly
> have a reason to choose a completely different license?
>

I gave my reason. You chose not to accept it, but that's not my problem.

-hpa

2003-03-07 15:22:36

by Kai Germaschewski

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, 7 Mar 2003, H. Peter Anvin wrote:

> Roman Zippel wrote:
> >
> > You are avoiding my question. If something goes into the kernel, the
> > kernel license would be the obvious choice. Granting additional rights or
> > using a dual license is a relatively small problem. But you must certainly
> > have a reason to choose a completely different license?
> >
>
> I gave my reason. You chose not to accept it, but that's not my problem.

Correct me, IANAL, but my understanding is that klibc will be dual
GPL/<whatever it is now> by inclusion into the kernel tree, after all the
whole purpose is to provide an initramfs which will be linked into vmlinux
(Yes, linked not in the normal sense, but still).

So it'd rather be similar to some parts of the kernel which are already
dual licensed (parts of ACPI I think being the latest example), and
patches will be assumed to be contributed under that dual license, unless
explicitly stated otherwise.

Or not?

--Kai

2003-03-07 18:27:13

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi,

On Fri, 7 Mar 2003, H. Peter Anvin wrote:

> > You are avoiding my question. If something goes into the kernel, the
> > kernel license would be the obvious choice. Granting additional rights or
> > using a dual license is a relatively small problem. But you must certainly
> > have a reason to choose a completely different license?
>
> I gave my reason. You chose not to accept it, but that's not my problem.

Could you please repeat your reasoning? I must have missed something.
So far I'm still trying to understand your choice and I haven't rejected
or accepted anything yet. So far I also tried to be careful not to give
any judgement, you're interpreting something into my words, I didn't
intend to say.

bye, Roman

2003-03-07 18:44:08

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, 7 Mar 2003, Roman Zippel wrote:
>
> Could you please repeat your reasoning? I must have missed something.

The reasoning is very simple:

- klibc is small. It would be pointless to make it a shared library,
because the infrastructure to do so and the indirection required would
likely be bigger than klibc itself (unless klibc is eventually bloated
up)

- klibc is potentially useful outside just standard kernel initrd images,
and in fact for development it is nice to use it that way.

Put the two together, and the GPL really doesn't look like a very good
license for klibc. Yeah, you can disagree about what the actual exceptions
are, but clearly there has to be _some_ exception to the license.

Also, since the kernel GPL thing doesn't taint user space apps (very much
documented since day 1), there really isn't any _reason_ to use the GPL in
the first place. klibc wouldn't ever get linked into the kernel, only into
apps.

As such, and since Peter is the main author, I don't see your argument,
Roman.

Linus

2003-03-07 19:10:43

by Matthew Wilcox

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

> As such, and since Peter is the main author, I don't see your argument,
> Roman.

klibc is losing at least some potential developers by virtue of its
licence. I'm not willing to release code under the BSD licence and would
prefer full GPL. I'm willing to compromise on LGPL, but Peter isn't.
He came out with some nonsense about wanting proprietary apps in early
userspace (which seems like a ludicrous thing to _favour_, but...) which
LGPL doesn't prevent you from doing, even with a non-shared library.

--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

2003-03-07 19:33:04

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Kai Germaschewski wrote:
>
> Correct me, IANAL, but my understanding is that klibc will be dual
> GPL/<whatever it is now> by inclusion into the kernel tree, after all the
> whole purpose is to provide an initramfs which will be linked into vmlinux
> (Yes, linked not in the normal sense, but still).
>

I don't actually think dual licensing is necessary, since the new
BSD/MIT license is generally considered to be GPL-compatible (i.e. it
grants all the rights the GPL does.) The dual license concept dates
back to the "old BSD" license, which definitely was *not* GPL-compatible.

> So it'd rather be similar to some parts of the kernel which are already
> dual licensed (parts of ACPI I think being the latest example), and
> patches will be assumed to be contributed under that dual license, unless
> explicitly stated otherwise.

This is pretty much it, except I believe explicit dual licensing is
superfluous. If anyone has evidence to the contrary please let me know.

-hpa

2003-03-07 19:48:39

by Alan

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, 2003-03-07 at 19:21, Matthew Wilcox wrote:
> prefer full GPL. I'm willing to compromise on LGPL, but Peter isn't.
> He came out with some nonsense about wanting proprietary apps in early
> userspace (which seems like a ludicrous thing to _favour_, but...) which
> LGPL doesn't prevent you from doing, even with a non-shared library.

Well you can use the BSD klibc code in your LGPL library, Peter just can't
get the changes back ;)

2003-03-07 21:45:10

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi,

On Fri, 7 Mar 2003, Linus Torvalds wrote:

> > Could you please repeat your reasoning? I must have missed something.
>
> The reasoning is very simple:
>
> - klibc is small. It would be pointless to make it a shared library,
> because the infrastructure to do so and the indirection required would
> likely be bigger than klibc itself (unless klibc is eventually bloated
> up)
>
> - klibc is potentially useful outside just standard kernel initrd images,
> and in fact for development it is nice to use it that way.
>
> Put the two together, and the GPL really doesn't look like a very good
> license for klibc. Yeah, you can disagree about what the actual exceptions
> are, but clearly there has to be _some_ exception to the license.

This really doesn't speak against the GPL, if we do something similiar as
libgcc. This gives users still enough freedom to whatever they want, e.g.
they can implement their own function to override the klibc one. Using GPL
would encourage people to contribute changes back. If they are not willing
to do this, they should have enough resources to reimplement the needed
functionality, anyway.

> Also, since the kernel GPL thing doesn't taint user space apps (very much
> documented since day 1), there really isn't any _reason_ to use the GPL in
> the first place. klibc wouldn't ever get linked into the kernel, only into
> apps.
>
> As such, and since Peter is the main author, I don't see your argument,
> Roman.

Well, there wasn't much to argue against yet so far :), I'm still trying
to find the reason for Peters decision.
If klibc becomes part of kernel, Peter is not the only author anymore and
people would be forced to contribute to a non GPL project (e.g. if I
wanted to get it working on m68k), which is part of a GPL project.
I smell some serious trouble ahead and that's why I'd really like to know
a good reason not to use the GPL (or a variant of it). This should
really carefully thought about now and not when it's too late.

bye, Roman

2003-03-07 22:57:03

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, 7 Mar 2003, Roman Zippel wrote:
> >
> > Put the two together, and the GPL really doesn't look like a very good
> > license for klibc. Yeah, you can disagree about what the actual exceptions
> > are, but clearly there has to be _some_ exception to the license.
>
> This really doesn't speak against the GPL, if we do something similiar as
> libgcc.

Sure. GPL with restrictions might work fine.

> Well, there wasn't much to argue against yet so far :), I'm still trying
> to find the reason for Peters decision.

That I can't answer. I don't personally think that BSD/MIT is any better
than GPL with restriction, and the real issue boils down to "what license
do people want to work on". Since Peter so far has been one of the major
developers, his opinion (regardless of _why_ he holds that opinion)
matters more than most to me.

Of course, some people have said that _they_ would want to work on it only
if it's GPL, but hey, the proof is in the pudding, and "A bird in the hand
is worth two in the bush". In other words, talk is cheap, and code rules.
Right now that means that hpa rules, methinks.

However, I also have to say that klibc is pretty late in the game, and as
long as it doesn't add any direct value to the kernel build the whole
thing ends up being pretty moot right now. It might be different if we
actually had code that needed it (ie ACPI in user space or whatever).

Linus

2003-03-07 23:30:13

by Russell King

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, Mar 07, 2003 at 03:05:32PM -0800, Linus Torvalds wrote:
> However, I also have to say that klibc is pretty late in the game, and as
> long as it doesn't add any direct value to the kernel build the whole
> thing ends up being pretty moot right now. It might be different if we
> actually had code that needed it (ie ACPI in user space or whatever).

Alan was recently trying to convince people that ipconfig.c should be
deleted from the 2.5 kernel today. That was until I pointed out that
people do download kernels via xmodem to embedded boards (because that's
what the boot loader supports) and they want to be able to use root-NFS.
I think Alan is reasonably happy for it to stay now, although I haven't
had any hard positive confirmation of that fact.

As long as we don't have equivalent functionality present which replaces
ipconfig.c and nfsroot.c without adding stupidly sized initrd images to
the kernel, I will continue to resist the removal of both of these
features.

klibc provided a way, but if that isn't going to be merged and this stuff
made to work for 2.6, then I think we must keep ipconfig.c and nfsroot.c.

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2003-03-07 23:37:32

by Greg KH

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, Mar 07, 2003 at 03:05:32PM -0800, Linus Torvalds wrote:
>
> However, I also have to say that klibc is pretty late in the game, and as
> long as it doesn't add any direct value to the kernel build the whole
> thing ends up being pretty moot right now. It might be different if we
> actually had code that needed it (ie ACPI in user space or whatever).

I know it's late, sorry.
But a lot of code that will need klibc, has not been converted to need
it yet, due to it not being there :)

If we add klibc to the build process, then those early boot processes
(like network boot, mounting of the root fs, acpi userspace parsers,
etc.) can later be added. Without it, the whole initramfs code is
pretty worthless right now. I purposely made these changesets up to
show how to use klibc, but not move any required functions over to it.

If you want to wait, and have me work on moving some of the existing
kernel code to userspace, using klibc, to prove it is needed in the
tree, I will be glad to do that. But in talking previously, I thought
the goal was to provide the functionality so that people can slowly move
those functions out of kernelspace, over time.

thanks,

greg k-h

2003-03-07 23:34:16

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Russell King wrote:
> On Fri, Mar 07, 2003 at 03:05:32PM -0800, Linus Torvalds wrote:
>
>>However, I also have to say that klibc is pretty late in the game, and as
>>long as it doesn't add any direct value to the kernel build the whole
>>thing ends up being pretty moot right now. It might be different if we
>>actually had code that needed it (ie ACPI in user space or whatever).
>
> Alan was recently trying to convince people that ipconfig.c should be
> deleted from the 2.5 kernel today. That was until I pointed out that
> people do download kernels via xmodem to embedded boards (because that's
> what the boot loader supports) and they want to be able to use root-NFS.
> I think Alan is reasonably happy for it to stay now, although I haven't
> had any hard positive confirmation of that fact.
>
> As long as we don't have equivalent functionality present which replaces
> ipconfig.c and nfsroot.c without adding stupidly sized initrd images to
> the kernel, I will continue to resist the removal of both of these
> features.
>
> klibc provided a way, but if that isn't going to be merged and this stuff
> made to work for 2.6, then I think we must keep ipconfig.c and nfsroot.c.

Right, of course. However, the first step (which Greg has accomplished)
is to get klibc merged into the kernel build. We already have ipconfig
and mount-nfs binaries which compile against klibc; now we need to
integrate them so they can pick up the ip= and nfsroot= options and do
the right thing in userspace.

*Then* we can discuss when they should be removed.

-hpa

2003-03-07 23:55:13

by Greg KH

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, Mar 07, 2003 at 03:53:44PM -0800, Linus Torvalds wrote:
> > But a lot of code that will need klibc, has not been converted to need
> > it yet, due to it not being there :)
>
> Yes. But that's not an argument that flies with me. I really want to see
> people actually using it, for real issues (even if they are potentially
> _small_ real issues).

Fair enough, I'll go work on this.

In the meantime, there were a number of fixes needed to the initramfs
code to get it to work properly for files. Will you take those small
fixes now so that everyone else can also start to play with a real
initramfs image?

thanks,

greg k-h

2003-03-07 23:46:48

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, 7 Mar 2003, Greg KH wrote:
>
> I know it's late, sorry.

Not a huge problem, since I don't think klibc itself is a stability issue.
However, as you say:

> But a lot of code that will need klibc, has not been converted to need
> it yet, due to it not being there :)

Yes. But that's not an argument that flies with me. I really want to see
people actually using it, for real issues (even if they are potentially
_small_ real issues).

I feel that people who want to work on early stuff can easily merge it
themselves (especially if they use BK), and show it to be useful. I don't
have the slightest feeling that work can't be done unless _I_ merge it.

Linus

2003-03-07 23:50:40

by Russell King

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, Mar 07, 2003 at 03:44:36PM -0800, H. Peter Anvin wrote:
> Right, of course. However, the first step (which Greg has accomplished)
> is to get klibc merged into the kernel build. We already have ipconfig
> and mount-nfs binaries which compile against klibc; now we need to
> integrate them so they can pick up the ip= and nfsroot= options and do
> the right thing in userspace.

Indeed - I think I made ipconfig dump out a file in a nice easy form
for other stuff to pick up on.

> *Then* we can discuss when they should be removed.

That is the order I always assumed this would happen in. 8)

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2003-03-08 00:27:53

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi,

On Fri, 7 Mar 2003, H. Peter Anvin wrote:

> Right, of course. However, the first step (which Greg has accomplished)
> is to get klibc merged into the kernel build. We already have ipconfig
> and mount-nfs binaries which compile against klibc; now we need to
> integrate them so they can pick up the ip= and nfsroot= options and do
> the right thing in userspace.

But before it's actually merged, I would slowly really like to know the
reasoning for license. You completely avoid that question and that makes
me nervous. Why did you choose this license over any GPL variant?
We could as well integrate dietlibc and if anyone has a problem with it,
he can still choose your klibc.
Why should I contribute to klibc instead of dietlibc?

bye, Roman

2003-03-08 00:37:59

by David Lang

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

The reason he gave back when the discussion was first started (months ago)
was that klibc is designed to be directly linked into programs, and it was
felt that this would not be possible with the GPL. In fact klibc was
adopted instead of dietlibc speceificly BECOUSE of the license.

while you could add an additional clause to the GPL to allow it to be
linked into programs directly the I seriously doubt if the self appointed
'GPL police' would notice the issue and would expect that fears on the
subject would limit it's use.

David Lang

On Sat, 8 Mar 2003, Roman Zippel wrote:

> Date: Sat, 8 Mar 2003 01:38:12 +0100 (CET)
> From: Roman Zippel <[email protected]>
> To: H. Peter Anvin <[email protected]>
> Cc: Russell King <[email protected]>,
> Linus Torvalds <[email protected]>, Greg KH <[email protected]>,
> [email protected]
> Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2
>
> Hi,
>
> On Fri, 7 Mar 2003, H. Peter Anvin wrote:
>
> > Right, of course. However, the first step (which Greg has accomplished)
> > is to get klibc merged into the kernel build. We already have ipconfig
> > and mount-nfs binaries which compile against klibc; now we need to
> > integrate them so they can pick up the ip= and nfsroot= options and do
> > the right thing in userspace.
>
> But before it's actually merged, I would slowly really like to know the
> reasoning for license. You completely avoid that question and that makes
> me nervous. Why did you choose this license over any GPL variant?
> We could as well integrate dietlibc and if anyone has a problem with it,
> he can still choose your klibc.
> Why should I contribute to klibc instead of dietlibc?
>
> bye, Roman
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2003-03-08 00:36:26

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Roman Zippel wrote:
>
> But before it's actually merged, I would slowly really like to know the
> reasoning for license. You completely avoid that question and that makes
> me nervous.
>

Actually I don't, you just don't like to hear the answer. I believe I
have stated and restated this several times already.

>
> Why did you choose this license over any GPL variant?
> We could as well integrate dietlibc and if anyone has a problem with it,
> he can still choose your klibc.
> Why should I contribute to klibc instead of dietlibc?
>

One more time, with feeling...

a) I, as well as the other early userspace developers, feel that the
advantages of allowing linking nonfree applications outweigh the
disadvantages.

b) I will personally go batty if I ever have to create yet another
implementation of printf() and the few other things in klibc that is
anything other than a thin shim over the kernel interface. The bottom
line is that klibc is so Linux-specific, that the only way someone would
"steal" code from it is because they want a specific subroutine
somewhere, and as far as I'm concerned, they can have it, and I don't
care in the slightest for what project.

-hpa

2003-03-08 00:39:31

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, 7 Mar 2003, Greg KH wrote:
>
> In the meantime, there were a number of fixes needed to the initramfs
> code to get it to work properly for files. Will you take those small
> fixes now so that everyone else can also start to play with a real
> initramfs image?

Sure, that makes sense. Send them over,

Linus

2003-03-08 00:55:04

by Greg KH

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Fri, Mar 07, 2003 at 04:47:43PM -0800, Linus Torvalds wrote:
>
> On Fri, 7 Mar 2003, Greg KH wrote:
> >
> > In the meantime, there were a number of fixes needed to the initramfs
> > code to get it to work properly for files. Will you take those small
> > fixes now so that everyone else can also start to play with a real
> > initramfs image?
>
> Sure, that makes sense. Send them over,

Great, just sent them.

thanks,

greg k-h

2003-03-08 01:17:47

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi,

On Fri, 7 Mar 2003, H. Peter Anvin wrote:

> a) I, as well as the other early userspace developers, feel that the
> advantages of allowing linking nonfree applications outweigh the
> disadvantages.

This is also possible with the GPL, see libgcc. What advantage has your
license to offer?

> b) I will personally go batty if I ever have to create yet another
> implementation of printf() and the few other things in klibc that is
> anything other than a thin shim over the kernel interface. The bottom
> line is that klibc is so Linux-specific, that the only way someone would
> "steal" code from it is because they want a specific subroutine
> somewhere, and as far as I'm concerned, they can have it, and I don't
> care in the slightest for what project.

Why do you make this decision for everyone?
If I wanted to use *BSD I would use it. The point of using Linux and
the GPL is that we at least attempt to protect the source to keep it free
and any contribution should be given the same respect. You insist on using
a different license, which would set a precedence with until now unknown
consequences. Your indifference in this matter is very alarming and
provokes only that klibc is very quickly replaced with yet another libc
implementation.

bye, Roman

2003-03-08 01:38:46

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi,

On Fri, 7 Mar 2003, David Lang wrote:

> The reason he gave back when the discussion was first started (months ago)
> was that klibc is designed to be directly linked into programs, and it was
> felt that this would not be possible with the GPL. In fact klibc was
> adopted instead of dietlibc speceificly BECOUSE of the license.

There is still the possibility to support multiple libc implementation, if
you don't like dietlibc, you're still free to use klibc.

> while you could add an additional clause to the GPL to allow it to be
> linked into programs directly the I seriously doubt if the self appointed
> 'GPL police' would notice the issue and would expect that fears on the
> subject would limit it's use.

Could we at least try to not let this degenerate into a flamewar? Thanks.

bye, Roman

2003-03-08 01:52:57

by David Lang

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Sat, 8 Mar 2003, Roman Zippel wrote:

> Hi,
>
> On Fri, 7 Mar 2003, David Lang wrote:
>
> > The reason he gave back when the discussion was first started (months ago)
> > was that klibc is designed to be directly linked into programs, and it was
> > felt that this would not be possible with the GPL. In fact klibc was
> > adopted instead of dietlibc speceificly BECOUSE of the license.
>
> There is still the possibility to support multiple libc implementation, if
> you don't like dietlibc, you're still free to use klibc.

along the same lines if you don't like klibc you are free to use or
implement dietlibc or anything else.

> > while you could add an additional clause to the GPL to allow it to be
> > linked into programs directly the I seriously doubt if the self appointed
> > 'GPL police' would notice the issue and would expect that fears on the
> > subject would limit it's use.
>
> Could we at least try to not let this degenerate into a flamewar? Thanks.

This was very much not intended to start a flamewar (and I do apologize if
anyone was offended by the post), but I think the very real fear of
oversealous GPL defenders is a large part of the reason why a modified GPL
was not chosen. The basic GPL was not chosen becouse the people
implementing klibc decided that the benifits of allowing propriatary code
outweighted the drawbacks as far as they are concerned.

I would love to see a lightweight libc that I could use for firewall
proxies and similar things that I have the source for but the license is
not GPL. The firewall toolkit proxies are an example, with libc5 I used to
put all the ones I used on a floppy to move them from one machine to
another, compiling with glibc there are some that won't fit on a floppy by
themselves, no functionality was gained in the process (and there is a
machine sitting under my desk that has a flash drive in it that I can't
use becouse they won't fit on it). it looks like klibc stands a good
chance of providing this.

David Lang

2003-03-08 01:56:55

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Russell King <[email protected]> writes:

> On Fri, Mar 07, 2003 at 03:05:32PM -0800, Linus Torvalds wrote:
> > However, I also have to say that klibc is pretty late in the game, and as
> > long as it doesn't add any direct value to the kernel build the whole
> > thing ends up being pretty moot right now. It might be different if we
> > actually had code that needed it (ie ACPI in user space or whatever).
>
> Alan was recently trying to convince people that ipconfig.c should be
> deleted from the 2.5 kernel today. That was until I pointed out that
> people do download kernels via xmodem to embedded boards (because that's
> what the boot loader supports) and they want to be able to use root-NFS.
> I think Alan is reasonably happy for it to stay now, although I haven't
> had any hard positive confirmation of that fact.

There is another reason ipconfig.c should die. Except in simple setups
it does the wrong thing. I have had it get a DHCP reply off of the wrong
NIC. Having the wrong policy in the kernel is a problem. Especially
when people think about fixing it...

> As long as we don't have equivalent functionality present which replaces
> ipconfig.c and nfsroot.c without adding stupidly sized initrd images to
> the kernel, I will continue to resist the removal of both of these
> features.

I agree ipconfig.c works well for development. Last time I played with
something like this it should not be hard to get the entire initrd
binary down to 30K-40K. I think you can probably do it in 16K but...

As far as equivalent functionality there is already a dhcp client and
a mount client in busybox. So in the worst case someone it will
take just a bit of glue to put these things together.

> klibc provided a way, but if that isn't going to be merged and this stuff
> made to work for 2.6, then I think we must keep ipconfig.c and
> nfsroot.c.

Either klibc or alternative user space implementation. There is no
reason that magic has to happen in the kernel. The only thing has
to be implemented is a way to smush a kernel and an initrd together.

Eric

2003-03-08 02:15:58

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

2003-03-08 15:40:52

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Russell King <[email protected]> writes:

> On Fri, Mar 07, 2003 at 07:06:42PM -0700, Eric W. Biederman wrote:
> > I agree ipconfig.c works well for development. Last time I played with
> > something like this it should not be hard to get the entire initrd
> > binary down to 30K-40K. I think you can probably do it in 16K but...
> >
> > As far as equivalent functionality there is already a dhcp client and
> > a mount client in busybox. So in the worst case someone it will
> > take just a bit of glue to put these things together.
>
> You didn't read my previous emails on this very subject. When you try to
> separate the dhcp client and mount client, you need some way to pass the
> information about which NFS server and path to mount to mount from dhcp.
> I have yet to find any DHCP client which allows this without the use of
> a shell and some parsing, which pushes the initrd through the roof.

I agree they both the dhcp client and the nfs mount need to be in the
same binary. With busybox they already are so it should just take
some glue code to have the magic work.

The last time I worked on something like this I put a dhcp client, and
a tftp client in a single binary, my compressed initrd was only 16K on
x86. And I had a complete network boot loader using the linux kernel.

Now the kernel is so big and bloated it has not been practical to use
it. So my effort has mostly been concentrated on etherboot. Which
is essentially a mini-kernel that just focuses on being a network boot
loader. And with etherboot I can get a udp/ip stack. With dhcp and
tftp support, and an eepro100 nic driver into 38K on an Itanium (The
platform with possible the most bloated binaries known to man). On x86
with an eepro100 driver I can usually get it down to around 16K. (All
sizes represent self decompressing executables).

And in etherboot there is support for mounting a nfs filesystem, and
reading a kernel off of that. Which makes it extremely relevant for
the question of how small can you get when replacing ipconfig.c

In truth putting the dhcp and mount clients in separate binaries
never occurred to me as a practical strategy.

> > > klibc provided a way, but if that isn't going to be merged and this stuff
> > > made to work for 2.6, then I think we must keep ipconfig.c and
> > > nfsroot.c.
> >
> > Either klibc or alternative user space implementation. There is no
> > reason that magic has to happen in the kernel. The only thing has
> > to be implemented is a way to smush a kernel and an initrd together.
>
> klibc is a user space C library, which incidentally supports ARM Thumb
> binaries natively. Here's some of the klibc ARM (non-thumb) executable
> sizes:
>
> -rwxrwxr-x 1 root root 784 Oct 21 16:22 bin/chroot
> -rwxrwxr-x 1 root root 4288 Oct 21 16:22 bin/dd
> -rwxrwxr-x 1 root root 1892 Oct 21 16:22 bin/fstype
> -rwxrwxr-x 1 root root 21348 Oct 21 16:22 bin/gzip
> -rwxr-xr-x 1 root root 1340 Oct 21 16:22 bin/init
> -rwxrwxr-x 1 root root 55396 Oct 21 16:22 bin/ip
> -rwxrwxr-x 1 root root 9260 Oct 21 16:22 bin/ipconfig
> -rwxrwxr-x 1 root root 2340 Oct 21 16:22 bin/mkdir
> -rwxrwxr-x 1 root root 1956 Oct 21 16:22 bin/mkfifo
> -rwxrwxr-x 1 root root 1988 Oct 21 16:22 bin/mount
> -rwxrwxr-x 1 root root 732 Oct 21 16:22 bin/pivot_root
> -rwxrwxr-x 1 root root 61412 Oct 21 16:22 bin/sh
> -rwxrwxr-x 1 root root 900 Oct 21 16:22 bin/umount
> -rwxrwxr-x 1 root root 54996 Oct 21 16:22 lib/klibc-0kmXIFHd5q4HQkCE6r3itw.so
>
>
> Note: all these utilities have been written to be as small as possible,
> and not all of these are absolutely required for a single-configuration
> system. There is very little code shared between these utilities.
>
> Even gzip has had lots of crap removed from it to shrink it down to size.
> `ip' is a hugely bloated way to configure IP networking - that binary
> only supports link, addr, and route functions.
>
> I challenge anyone to find binaries that are smaller than these, but
> contain the same functionality (ie, no surprises that something doesn't
> work the way it should do.) Note: busybox is not functionally the same.
> Been there already.

I'm lost. Why is there a complete userspace here? I guess this
explains why klibc is not useful yet. This is definitely not a route
for what is required to just replace the kernel pieces like ipconfig.c

I knew something was fishy when we got beyond having a single
executable. This is where I mumble that it was once possible to
run unix in 64K. (32K kernel 32K user space) So why can't we get
small binaries anymore?

> Things the current klibc setup is able to do:
>
> - bringing up networking.
> - detecting a local filesystem type.
> - mounting a _local_ filesystem.
> - gunzipping a ramdisk image from a device and loading it into a ramdisk.
>
> Things klibc stuff can't do at present:
>
> - be configurable from the kernel command line. If something goes wrong
> with the boot, you need to rebuild the early userspace image to do
> something different.
> - mount NFS-root filesystems.
> - be as small as the current kernel solution. Current early userspace
> weighs in at 220K (uncompressed) on ARM, or a 97K gzipped ext2fs image.

That is definitely still a heavy weight. Not to bad for a general
purpose setup but not really good either.

> A solution for the first requires all the existing infrastructure in
> the kernel (which traps things like "ro", "root=" and so forth) to
> be removed.

Or a different set of option names be used in the interim.

> A solution for the final point is possible - you combine everything
> together into one large image, get rid of the shell, and produce one
> honking monolitic kitchen sink that couldn't care whether you have
> NFS support in the kernel or not.

Exactly. And you build it for the specific purpose of just
configuring the system. And by not handling the general case you
should be able to get another significant size reduction.

> Please note - I have a working setup here which:
>
> - decompresses the initramfs ext2 image from a MTD flash partition
> - sets up networking using dhcp
> - decompresses the real root ramdisk into another ramdisk
> - detects the type of the filesystem
> - mounts the filesystem
> - pivot-root's to the root filesystem
> - starts init
>
> This works for me. Others milage will vary drastically because klibc
> needs more work.
>
> Oh, I may seem to be enthusiastic about klibc. I haven't worked on it
> since October last year, mainly because it didn't seem to be going anywhere
> fast (like, into the kernel.) I'm not intending spending anymore time
> on it until there's some improvement in this area, which would allow more
> stuff to happen in klibc.

Reasonable I guess.

Eric

2003-03-08 15:46:17

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On 7 Mar 2003, David S. Miller wrote:
> On Fri, 2003-03-07 at 18:26, Roman Zippel wrote:
>
> > This is simply not true, if the usage terms are clearly defined in
> > advance, we can easily easily ignore the trolls. Did anyone ever complain
> > about the libgcc license? I don't think your fear is justified.
>
> I agree with Roman, I see no reason why the libgcc
> license could not be used.

Guys, which part of "he who writes the code gets to choose the license"
do you not _get_?

I find few things more morally offensive than whiners who whine about
other peoples choice of license.

I found it totally inappropriate when some of the crazier BSD guys were
whining about the use of the GPL in Linux for _years_. They seem to
finally have shut up lately, or maybe I've just gotten sufficiently good
at ignoring them.

But I find it _equally_ offensive when somebody whines the other way. I
can understand it from rms, if only because I _expect_ it. But why the
hell people who didn't actually DO anything whine about Peter's choice of
license FOR THE CODE HE WROTE, I don't see.

This is the "shut up and put up" philosophy of software licensing. Either
you do the work, or you sit quietly and watch others do it. If you do the
work, you get to impact the license. If you don't, you had better SHUT THE
F*CK UP!

Btw, the same goes for every single BK whiner out there.

Linus "hotbutton" Torvalds

2003-03-08 16:02:39

by Russell King

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Sat, Mar 08, 2003 at 08:50:48AM -0700, Eric W. Biederman wrote:
> Exactly. And you build it for the specific purpose of just
> configuring the system. And by not handling the general case you
> should be able to get another significant size reduction.

You do not want to be too specific though - a kernel with features
X, Y, and Z in the current setup can boot using any of those features
by just supplying the appropriate command line.

The reason HPA wanted to go down the userspace route, btw, was to
support additional add-ons for bringing other stuff up - remember this
is part of the initramfs spec that was reviewed by this list many
months ago? Or has that now gone completely out of the window?

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2003-03-08 16:11:31

by David Miller

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

From: Linus Torvalds <[email protected]>
Date: Sat, 8 Mar 2003 07:54:02 -0800 (PST)

On 7 Mar 2003, David S. Miller wrote:
> I agree with Roman, I see no reason why the libgcc
> license could not be used.
...
If you do the
work, you get to impact the license. If you don't, you had better SHUT THE
F*CK UP!

Note how I used the word "could" not "should" or "must".

Should I really SHUT THE F*CK UP as you suggest?

I totally agree with your position about who gets to decide
the license. I thought the issue was one of usability, not personal
choice.

2003-03-08 16:27:24

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Sat, 8 Mar 2003, David S. Miller wrote:
>
> Note how I used the word "could" not "should" or "must".

Yeah. And I note how Roman and others also didn't say "you _must_ change
it to the GPL".

The thing is, this discussion has _not_ been exactly neutral. You may have
said "could" or "might" or whatever, but clearly people are trying to
pressure hpa into going to GPL. It's the whole tone of the thread.

Or would you disagree with that?

Hey, I'm a GPL user myself, obviously. I don't much like the BSD license,
and no project _I_ start is likely to ever be under that license. In fact,
I seriously doubt that I'd ever really even want to get seriously involved
with a project that could just be hijacked without source at any time.

However, that doesn't make pressuring hpa about it ok.

Also, you guys should think about what this whole project was about: it's
about the smallest possible libc. This is NOT a project that should live
and prosper and grow successful. That's totally against the whole point of
it, it's not _supposed_ to ever be a glibc-like thing. It's supposed to be
so damn basic that it's not even _interesting_. It's one of those projects
that is better off ignored, in fact. It's like a glorified header file.

(At this point hpa asks me to shut up, since I've now depressed him more
than any of the GPL bigots ever did ;)

I can _totally_ see hpa's point that he would be perfectly happy with
people "stealing" parts of it - the code in question is not something that
anybody should _ever_ have to re-create, even if he's the most evil person
on earth and hates the GPL and wants to kill us all. Because it's not
_worth_ recreating.

Linus

2003-03-08 16:30:39

by David Miller

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

From: Linus Torvalds <[email protected]>
Date: Sat, 8 Mar 2003 08:35:24 -0800 (PST)

The thing is, this discussion has _not_ been exactly neutral. You may have
said "could" or "might" or whatever, but clearly people are trying to
pressure hpa into going to GPL. It's the whole tone of the thread.

Or would you disagree with that?

The tone of parts of this thread, sure.

Did my intentions match this? Absolutely not.

I couldn't justify my use of bitkeeper if I didn't believe in
personal choice about licenses.

2003-03-08 16:45:02

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi,

On Fri, 7 Mar 2003, David Lang wrote:

> > There is still the possibility to support multiple libc implementation, if
> > you don't like dietlibc, you're still free to use klibc.
>
> along the same lines if you don't like klibc you are free to use or
> implement dietlibc or anything else.

Ok, it seems this requires a larger explanation.
It doesn't matter what you or I like. As long as dietlibc or klibc and
linux are separate projects, I don't care much about the license. I have
little problems to contribute to a BSD project, if you look at the m68k
fpu emulator you will find a dual license. I hope this makes it clear that
I'm not against the BSD license.

The problem starts as soon as klibc becomes part of the linux kernel, as
it would give a clear preference to similiar projects as dietlibc. It's
hard to imagine, that this will not cause any problem. The easiest
solution would be relicense klibc under a license which is closer to the
kernel license, but on the other hand meets the requirements the current
license was choosen for. AFAICS a libgcc like license would do this job,
but Peter made it very clear, that he does not want a different license,
although it's unfortunately unclear why, but I have to respect that.

This means now we have to come back to the original problem: what problems
might occur, if klibc is integrated and distributed with the kernel? Will
it be possible to use dietlibc? What does that mean for other early
userspace code, has to be licensed under the klibc license? Can I take
source from a GPL project and integrate that into klibc?
I think it's important to discuss such questions now, as long as still
possible without a lawyer, is the module story not warning enough?
My opinion at this point is, as long as Peter avoids to dicuss these
issues, we should also consider to avoid integrating klibc in the kernel.

bye, Roman

2003-03-08 16:56:48

by [email protected]

[permalink] [raw]

Subject: RE: [BK PATCH] klibc for 2.5.64 - try 2

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Roman Zippel
> Sent: Saturday, March 08, 2003 10:55 AM
> To: David Lang
> Cc: H. Peter Anvin; Russell King; Linus Torvalds; Greg KH;
> [email protected]
> Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2
> but Peter made it very clear, that he does not want a
> different license,
> although it's unfortunately unclear why, but I have to respect that.

You should clarify there "Unclear to those of us who've had a frontal
labotomy why,"

It's more than clear. You are the only one who doesn't accept that.

--

/"\ / For information and quotes, email us at
\ / ASCII RIBBON CAMPAIGN / [email protected]
X AGAINST HTML MAIL / http://www.lrsehosting.com/
/ \ AND POSTINGS / [email protected]
-------------------------------------------------------------------------

2003-03-08 16:57:14

by Larry McVoy

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Sat, Mar 08, 2003 at 08:35:24AM -0800, Linus Torvalds wrote:
> Also, you guys should think about what this whole project was about: it's
> about the smallest possible libc. This is NOT a project that should live
> and prosper and grow successful. That's totally against the whole point of
> it, it's not _supposed_ to ever be a glibc-like thing. It's supposed to be
> so damn basic that it's not even _interesting_. It's one of those projects
> that is better off ignored, in fact. It's like a glorified header file.
>
> (At this point hpa asks me to shut up, since I've now depressed him more
> than any of the GPL bigots ever did ;)

Actually, I think this libc is very useful and at the risk of depressing hpa
even more, we may well link BitKeeper against it. We make no use of anything
glibc specific since we run on all sorts of platforms and having libc be
part of the image would be cool if it were small.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

2003-03-08 20:14:21

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

On Sat, 8 Mar 2003, Larry McVoy wrote:
>
> Actually, I think this libc is very useful and at the risk of depressing hpa
> even more, we may well link BitKeeper against it. We make no use of anything
> glibc specific since we run on all sorts of platforms and having libc be
> part of the image would be cool if it were small.

Mixing basic libraries on the same host can be a damn pain, which is one
reason why libraries have a hard time getting competition (and if they
don't have competition, they have little incentives to becomes smaller and
leaner and faster)

For example, I bet you'll find problems with simple things like
disagreements over configuration. Things like user/host lookups (NIS,
files, whatever?) etc. You'll get BK to behave differently from other
binaries because it uses a different library that is configured
differently..

And then there will be some feature that isn't there, because the klibc
people really don't care. So then you'll have a mixed environment..

Yeah, it sucks. A basic standard C library _should_ probably be so small
that it really doesn't make any real sense to have shared libraries for it
at all. But because of all the nasty corner cases for the "extended
functionality", you often end up wanting to lump a lot of new stuff into
the standard library, so you get all these connections that are hard to
break.

And nobody wants to have to add "-lresolv" (or even "-lm") etc to their
builds, so there's the user base too that by being lazy really advocates a
big library. And once it is big it really wants to be shared. And once
_that_ happens, you want even more to combine libraries that would
otherwise have been fine as two separate libs, since you don't want to
make the startup costs worse than they already are by having to mmap many
different files.

In short: some stuff would be better off static, simply because it's
smaller that way, and it helps startup costs if it can be all linked into
the binary. But it's _only_ smaller if you don't have to do the dynamic
linking _anyway_, which means that the cases where it really pays off are
only for the simple stuff.

And there's a _lot_ of simple stuff, but even then you have to live
together with stuff that isn't simple, so now the simple stuff has to live
by the rules of the complex stuff. And the complex stuff doesn't mind
doing complex things if it makes other things more convenient, so the
complex parts really don't care about living together with the small and
simple stuff.

Yeah, I'm pessimistic. It's just _damned_hard_ to be small any more, when
you have to live in harmony with projects that long since stopped caring
about the small stuff, because it just didn't even register on their
radar any more.

Linus

2003-03-08 20:46:34

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Linus Torvalds wrote:
>
> Also, you guys should think about what this whole project was about: it's
> about the smallest possible libc. This is NOT a project that should live
> and prosper and grow successful. That's totally against the whole point of
> it, it's not _supposed_ to ever be a glibc-like thing. It's supposed to be
> so damn basic that it's not even _interesting_. It's one of those projects
> that is better off ignored, in fact. It's like a glorified header file.
>
> (At this point hpa asks me to shut up, since I've now depressed him more
> than any of the GPL bigots ever did ;)
>

Hardly, since that's exactly the point :)

> I can _totally_ see hpa's point that he would be perfectly happy with
> people "stealing" parts of it - the code in question is not something that
> anybody should _ever_ have to re-create, even if he's the most evil person
> on earth and hates the GPL and wants to kill us all. Because it's not
> _worth_ recreating.

This is exactly the point. The most interesting code in there is
printf() and scanf(), and I'm personally utterly sick of having to
recreate that code for various projects due to licensing incompatiblities.

-hpa

2003-03-08 20:42:56

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Eric W. Biederman wrote:
>
> I agree they both the dhcp client and the nfs mount need to be in the
> same binary. With busybox they already are so it should just take
> some glue code to have the magic work.
>

Not necessarily -- you could pass the DHCP packets in binary file form.
This would also let the boot loader pass the DHCP packets instead.

-hpa

2003-03-08 20:50:05

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Russell King <[email protected]> writes:

> On Sat, Mar 08, 2003 at 08:50:48AM -0700, Eric W. Biederman wrote:
> > Exactly. And you build it for the specific purpose of just
> > configuring the system. And by not handling the general case you
> > should be able to get another significant size reduction.
>
> You do not want to be too specific though - a kernel with features
> X, Y, and Z in the current setup can boot using any of those features
> by just supplying the appropriate command line.
>
> The reason HPA wanted to go down the userspace route, btw, was to
> support additional add-ons for bringing other stuff up - remember this
> is part of the initramfs spec that was reviewed by this list many
> months ago? Or has that now gone completely out of the window?

I don't recall anything about the contents of initramfs being specified.
What I was expecting to see was a good set of general purpose policies
being included in the default kernel binary. And just replacing
/sbin/kinit if I wanted something dramatically different. And that is
what I remember Al Viro working on.

So I don't think building a very specific /sbin/kinit that
only does what the kernel currently does right now is a problem.

initramfs looks very nice as it cleans up a lot of problems with building
ext2fs filesystem images on the fly. And it let's me use a ramfs filesystem
from the start. On systems I am looking at in the future that will enable
me to compile out the block layer entirely.

Currently I have all of the features initramfs promises, and they get
routinely used. The initramfs stuff is just an incremental
improvement that should makes things cleaner and smaller. All of my
policy is already in user space and as I boot over the network size is
not a large constraint. And I still boot up fast enough that I
occasionally have problems with my hard drivers not being spun up yet.

So I like the initramfs spec.

And I like the idea of having a library that makes it easy to
build new small user space binaries.

In the cases where things are sufficiently general that I need
a script interpreter I don't want klibc and /bin/sh. I want glibc
and /bin/bash. Because at that point I will be throwing random
executables at need from a working system anyway. And having to
recompile everything to be tiny is not flexible. This issue has
come up multiple times when the design of an initrd for one purpose or
another has been considered and every time the sheer flexibility and
simplicity of using the normal user space wins out over some tiny
solution.

There may be some usage point where a little extra flexibility
is paid for by having a command interpreter and separate binaries but
I don't currently see it. Either I am very general in which point klibc
is to inflexible. Or I am very specific at which point I can put
everything into a /sbin/kinit.

So I think we should have a very small very specific /sbin/kinit
that does in user space what the kernel does in kernel space right
now. Regardless of klibc the default /sbin/kinit should be gpl'd
because we are moving code from code from the kernel into it, and we
shouldn't need to double check the licenses to move code from the
kernel into it.

There are things that would be nice to get in there like the lvm
configuration tools and the like so you can have some more
sophisticated mount options. But I don't much care. It is only the
kernel's default policy and it can be replaced.

For cases where you need a very different policy with all of the
embedded libc's currently out there. klibc, uclibc, dietlibc it
should not be hard to make your own /sbin/kinit.

Eric

2003-03-08 20:52:08

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Followup to: <[email protected]>
By author: Larry McVoy <[email protected]>
In newsgroup: linux.dev.kernel
>
> Actually, I think this libc is very useful and at the risk of depressing hpa
> even more, we may well link BitKeeper against it. We make no use of anything
> glibc specific since we run on all sorts of platforms and having libc be
> part of the image would be cool if it were small.
>

You may want to read the klibc CAVEATS file before you start thinking
in that direction...

-hpa

--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

2003-03-08 20:58:16

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Eric W. Biederman wrote:
>
> I don't recall anything about the contents of initramfs being specified.
> What I was expecting to see was a good set of general purpose policies
> being included in the default kernel binary. And just replacing
> /sbin/kinit if I wanted something dramatically different. And that is
> what I remember Al Viro working on.
>
> So I don't think building a very specific /sbin/kinit that
> only does what the kernel currently does right now is a problem.
>

It does matter how the initramfs is built. /bin/sh may or may not be
necessary (but klibc /bin/sh is just over 50K on i386 -- 55K static,
whereas glibcx /bin/bash is 600K plus the glibc binary), but one of the
goals with initramfs is to at least make it feasible to give someone who
comes and asks "I have a weird-ass site with 20000 hosts and we need X"
a better answer then "well, go hack the kernel."

/sbin/kinit is a feasible way to do it, but it's important to keep the
flexibility option open.

> So I think we should have a very small very specific /sbin/kinit
> that does in user space what the kernel does in kernel space right
> now. Regardless of klibc the default /sbin/kinit should be gpl'd
> because we are moving code from code from the kernel into it, and we
> shouldn't need to double check the licenses to move code from the
> kernel into it.

Agreed (although it's harder than you think to move code from the kernel
into it -- frequently it has been easier to just write code from
scratch; it's cleaner that way, too.)

The reason I wanted to use BSD/MIT license only really applies to the
library.

-hpa

2003-03-08 21:00:22

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Eric W. Biederman wrote:
>
> The last time I worked on something like this I put a dhcp client, and
> a tftp client in a single binary, my compressed initrd was only 16K on
> x86. And I had a complete network boot loader using the linux kernel.
>
> Now the kernel is so big and bloated it has not been practical to use
> it. So my effort has mostly been concentrated on etherboot. Which
> is essentially a mini-kernel that just focuses on being a network boot
> loader. And with etherboot I can get a udp/ip stack. With dhcp and
> tftp support, and an eepro100 nic driver into 38K on an Itanium (The
> platform with possible the most bloated binaries known to man). On x86
> with an eepro100 driver I can usually get it down to around 16K. (All
> sizes represent self decompressing executables).
>

Incidentally, any hope of getting Etherboot to act as a PXE stack any
time soon?

-hpa (ducks & runs)

2003-03-09 01:14:37

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi,

On Sat, 8 Mar 2003, Linus Torvalds wrote:

> The thing is, this discussion has _not_ been exactly neutral. You may have
> said "could" or "might" or whatever, but clearly people are trying to
> pressure hpa into going to GPL. It's the whole tone of the thread.
>
> Or would you disagree with that?

Um, I have to. What I was trying to is to get a clear answer, why he does
not want a different license. All arguments I heard so far don't speak
against a libgcc like license. I only want to know whether there is an
alternative solution he might also be comfortable with.
I don't want to pressure him into anything, I only sort of expect, if
someone makes a decision, which might have farreaching consequences, that
he is able to explain and defend his decision. All I want is that people
sometimes think what consequences their action might have. This is the
point I'm missing here a bit.

bye, Roman

2003-03-09 01:19:41

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

"H. Peter Anvin" <[email protected]> writes:

> Eric W. Biederman wrote:
> > The last time I worked on something like this I put a dhcp client, and
> > a tftp client in a single binary, my compressed initrd was only 16K on
> > x86. And I had a complete network boot loader using the linux kernel.
> > Now the kernel is so big and bloated it has not been practical to use
> > it. So my effort has mostly been concentrated on etherboot. Which
> > is essentially a mini-kernel that just focuses on being a network boot
> > loader. And with etherboot I can get a udp/ip stack. With dhcp and
> > tftp support, and an eepro100 nic driver into 38K on an Itanium (The
> > platform with possible the most bloated binaries known to man). On x86
> > with an eepro100 driver I can usually get it down to around 16K. (All
> > sizes represent self decompressing executables).
> >
>
> Incidentally, any hope of getting Etherboot to act as a PXE stack any time soon?

Etherboot is unlikely to support UNDI.

However there is already some code that was integrated that exports
the UDP/TFTP layers PXE clients use. The code just needs some
cleanups so that it works, maybe weeks worth of work. All of the
calls pxelinux use are already present.

> -hpa (ducks & runs)

I prefer an interface that does not need callbacks, things are just
plain simpler. But when the callback is easy and there already is a
better mechanism I don't have a problem with it.

Of course it is worth noting that PXE runtime support on the itanium
does not even resemble PXE runtime support on x86. Unlike unix it
does not have a stable API.

Eric

2003-03-09 01:35:55

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Eric W. Biederman wrote:
>
> Of course it is worth noting that PXE runtime support on the itanium
> does not even resemble PXE runtime support on x86. Unlike unix it
> does not have a stable API.
>

That doesn't surprise me. Of course, that doesn't change my opinion
about Itanic in any way :)

-hpa

2003-03-09 02:15:09

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

"H. Peter Anvin" <[email protected]> writes:

> Eric W. Biederman wrote:
> > I don't recall anything about the contents of initramfs being specified.
> > What I was expecting to see was a good set of general purpose policies
> > being included in the default kernel binary. And just replacing
> > /sbin/kinit if I wanted something dramatically different. And that is
> > what I remember Al Viro working on.
> > So I don't think building a very specific /sbin/kinit that
> > only does what the kernel currently does right now is a problem.
> >
>
> It does matter how the initramfs is built. /bin/sh may or may not be necessary
> (but klibc /bin/sh is just over 50K on i386 -- 55K static, whereas glibcx
> /bin/bash is 600K plus the glibc binary), but one of the goals with initramfs is
>
> to at least make it feasible to give someone who comes and asks "I have a
> weird-ass site with 20000 hosts and we need X" a better answer then "well, go
> hack the kernel."

I agree the size of glibc 1.1M and /bin/bash 600K are substantial.
And in most cases if I had to drop one it would be /bin/bash. But 2M
is not that bad if you already need 14M for your modules.

There are still cases where you need to fit through a very narrow pipe
like a floppy, and for those any extra size is a show stopper. But I
also don't see needing a lot of flexibility after coming through a
very narrow pipe.

> /sbin/kinit is a feasible way to do it, but it's important to keep the
> flexibility option open.

I agree, flexibility is important.

My basic point was it sounds like the development process is backwards.
It feels like we are starting big and then going small, instead of the
other way around.

And if starting big keeps the code from being incorporated into
the kernel, I'm not in favor of it. I am in favor of any code that
works.

How I have always expected to use this code is to either use
what is provided in the kernel or replace it entirely.

> > So I think we should have a very small very specific /sbin/kinit
> > that does in user space what the kernel does in kernel space right
> > now. Regardless of klibc the default /sbin/kinit should be gpl'd
> > because we are moving code from code from the kernel into it, and we
> > shouldn't need to double check the licenses to move code from the
> > kernel into it.
>
> Agreed (although it's harder than you think to move code from the kernel into it
>
> -- frequently it has been easier to just write code from scratch; it's cleaner
> that way, too.)

I am not surprised. In kernel and out of the kernel the APIs are noticeably
different.

There are some things like table parsers that I expect would remain unchanged
moving from kernel to user space. Using the information would be quite
different but the same data structures could be used to represent it.

The important thing is when people have an itch to move code they can glance
at it and not have to worry about the license. If something looks hard
at first glance it might not happen. If it looks easy it more likely to happen
even if it is hard :)

> The reason I wanted to use BSD/MIT license only really applies to the library.

Quite reasonable, and I have no problem with BSD/MIT for just the
library as long as it has a GPL compatible license.

Eric

2003-03-09 02:19:32

by Larry McVoy

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

> I agree the size of glibc 1.1M and /bin/bash 600K are substantial.
> And in most cases if I had to drop one it would be /bin/bash. But 2M
> is not that bad if you already need 14M for your modules.

[...]

> My basic point was it sounds like the development process is backwards.
> It feels like we are starting big and then going small, instead of the
> other way around.

Truer words were never spoken. Less is more.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

2003-03-09 02:27:40

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

"H. Peter Anvin" <[email protected]> writes:

> Eric W. Biederman wrote:
> > Of course it is worth noting that PXE runtime support on the itanium
> > does not even resemble PXE runtime support on x86. Unlike unix it
> > does not have a stable API.
> >
>
> That doesn't surprise me. Of course, that doesn't change my opinion about
> Itanic in any way :)

And I thought I was talking about PXE....

Eric

2003-03-09 11:22:00

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Am Sam, 2003-03-08 um 18.28 schrieb Eric W. Biederman:

> All of my policy is already in user space and as I boot over the
> network size is not a large constraint.

Just curious, for me size *is* a large constraint just because I'm
booting over network. The size of a kernel must not exceed 1M in
size here and that brought me quite some troubles with the growth
of 2.5.x. How did you get around this?

--
Servus,
Daniel

Attachments:

signature.asc (189.00 B)
Dies ist ein digital signierter Nachrichtenteil

2003-03-09 11:36:45

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Daniel Egger <[email protected]> writes:

> Am Sam, 2003-03-08 um 18.28 schrieb Eric W. Biederman:
>
> > All of my policy is already in user space and as I boot over the
> > network size is not a large constraint.
>
> Just curious, for me size *is* a large constraint just because I'm
> booting over network. The size of a kernel must not exceed 1M in
> size here and that brought me quite some troubles with the growth
> of 2.5.x. How did you get around this?

I use etherboot. It is small and has not problems acting as network
bootstrap program if you are stuck with EFI.

Etherboot can load to any address < 4GB and can jump to a 32bit entry
point. It's not rocket science or magic just good open source code.

Eric

2003-03-09 14:08:53

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Am Son, 2003-03-09 um 12.46 schrieb Eric W. Biederman:

> I use etherboot. It is small and has not problems acting as network
> bootstrap program if you are stuck with EFI.

Sorry for being unclear here; I'm neither using IA64 nor EFI. This is
plain etherboot resp. PXE/etherboot on ia32.

> Etherboot can load to any address < 4GB and can jump to a 32bit entry
> point. It's not rocket science or magic just good open source code.

Maybe etherboot isn't the culprit here, but mknbi won't let me
create bigger tagged boot kernels.

--
Servus,
Daniel

Attachments:

signature.asc (189.00 B)
Dies ist ein digital signierter Nachrichtenteil

2003-03-10 00:39:27

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Followup to: <1047219550.4102.6.camel@sonja>
By author: Daniel Egger <[email protected]>
In newsgroup: linux.dev.kernel
>
> > Etherboot can load to any address < 4GB and can jump to a 32bit entry
> > point. It's not rocket science or magic just good open source code.
>
> Maybe etherboot isn't the culprit here, but mknbi won't let me
> create bigger tagged boot kernels.
>

Try pxelinux... it doesn't need any kind of tagging.

-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

2003-03-10 01:30:27

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Am Mon, 2003-03-10 um 01.49 schrieb H. Peter Anvin:

> Try pxelinux... it doesn't need any kind of tagging.

Unfortunately I couldn't get it to work when I tried last
time and now I've too many machines running on the good ol'
double hit tftp scheme to make a switch quite cumbersome.

But you're right, I should definitely try it. I've two questions
regarding it though:
- Right now I've several machines having etherboot on flash, how
can I use pxelinux (or similar) with them? I don't want to have
two quite different ways to deal with.
- Are there any kind of constraints which annoy me right now
with etherboot/mknbi like maximum kernel size < 1M?

--
Servus,
Daniel

Attachments:

signature.asc (189.00 B)
Dies ist ein digital signierter Nachrichtenteil

2003-03-10 05:52:15

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Daniel Egger <[email protected]> writes:

> Am Son, 2003-03-09 um 12.46 schrieb Eric W. Biederman:
>
> > I use etherboot. It is small and has not problems acting as network
> > bootstrap program if you are stuck with EFI.
>
> Sorry for being unclear here; I'm neither using IA64 nor EFI. This is
> plain etherboot resp. PXE/etherboot on ia32.
>
> > Etherboot can load to any address < 4GB and can jump to a 32bit entry
> > point. It's not rocket science or magic just good open source code.
>
> Maybe etherboot isn't the culprit here, but mknbi won't let me
> create bigger tagged boot kernels.

Hmm. I don't know. It looks like a tool chain problem. Maybe
a very old/strange version of mknbi. I have never seen a 1MB limit
on any of the tools. Though I have not played with the version of
mknbi that came with netboot.

Anyway if you re-ask on the etherboot-users list I am certain someone
can get this sorted out for you.

Eric

2003-03-10 20:22:49

by Hans-Peter Jansen

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi Daniel,

On Sunday 09 March 2003 15:19, Daniel Egger wrote:
> Am Son, 2003-03-09 um 12.46 schrieb Eric W. Biederman:
>
> > Etherboot can load to any address < 4GB and can jump to a 32bit entry
> > point. It's not rocket science or magic just good open source code.
>
> Maybe etherboot isn't the culprit here, but mknbi won't let me
> create bigger tagged boot kernels.

The biggest bootimage I'm using here is (SuSE 8.2b3 Inst. Kernel+initrd):
-r--r--r-- 1 nobody nogroup 6009856 Mar 6 10:07 bootimage-ziggy
created with mknbi-linux V1.2, so this isn't really the problem.
I'm also using ~4MB sized dos boot images (PQMagic, BIOS updates) without
problems. Don't try this with floppies...

Etherboot is simply pure fun and saved my life a couple of times ;-)

Thanks, Eric!

Bye,
Pete

2003-03-10 22:11:16

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Am Mon, 2003-03-10 um 21.33 schrieb Hans-Peter Jansen:

> The biggest bootimage I'm using here is (SuSE 8.2b3 Inst. Kernel+initrd):
> -r--r--r-- 1 nobody nogroup 6009856 Mar 6 10:07 bootimage-ziggy
> created with mknbi-linux V1.2, so this isn't really the problem.
> I'm also using ~4MB sized dos boot images (PQMagic, BIOS updates) without
> problems. Don't try this with floppies...

> Etherboot is simply pure fun and saved my life a couple of timesm ;-)

Hrm, as it turned out I had my scripts pointing to the netboot version
of mknbi (I remember vaguely having troubles with the etherboot version
back when I started netbooting) which seems to be somewhat limited.

A short test with the 1.2 version of the etherboot mknbi-linux worked as
expected, YAY! Now back to the try to boot a working 2.5 kernel. :)

Thanks for your help!

--
Servus,
Daniel

Attachments:

signature.asc (189.00 B)
Dies ist ein digital signierter Nachrichtenteil

2003-03-12 22:53:51

by Pavel Machek

[permalink] [raw]

Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2

Hi!

> > b) I will personally go batty if I ever have to create yet another
> > implementation of printf() and the few other things in klibc that is
> > anything other than a thin shim over the kernel interface. The bottom
> > line is that klibc is so Linux-specific, that the only way someone would
> > "steal" code from it is because they want a specific subroutine
> > somewhere, and as far as I'm concerned, they can have it, and I don't
> > care in the slightest for what project.
>
> Why do you make this decision for everyone?
> If I wanted to use *BSD I would use it. The point of using Linux and
> the GPL is that we at least attempt to protect the source to keep it free
> and any contribution should be given the same respect. You insist on using

I believe HPA wants klibc to stay small,
and BSD license will act as contribution-
stopper, therefore keeping it small...

Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

2003-03-13 00:12:19