* [BK PATCH] klibc for 2.5.64 - try 2
@ 2003-03-07 0:16 Greg KH
2003-03-07 1:02 ` Roman Zippel
0 siblings, 1 reply; 63+ messages in thread
From: Greg KH @ 2003-03-07 0:16 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Hi,
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.
Please pull from:
bk://kernel.bkbits.net/gregkh/linux/klibc-2.5
If you have any problems or questions with them, please let me know.
I've attached a short changelog of the different things in this
repository below, along with a diffstat of the resulting changes
Note, the Cset exclude is for Kai's cset that moved mounting of the root
fs into userspace, we can start making those kind of changes later. The
only changes here is to add klibc to the build, and add a small example
program to the initramfs image that gets unpacked at boot time and run.
I've also placed a patch of all of this, against a clean 2.5.64 kernel
at:
kernel.org/pub/linux/kernel/people/gregkh/klibc/klibc-2.5.64.patch.gz
for those who don't want to use BitKeeper.
thanks,
greg k-h
--------------
Changes from your bk tree:
Arnd Bergmann <arnd@bergmann-dalldorf.de>:
o KLIBC: fix for non-i386 build
Arnd Bergmann <arndb@de.ibm.com>:
o klibc: gen_init_cpio file generation fix
Greg Kroah-Hartman <greg@kroah.com>:
o KLIBC: added LICENSE file for klibc portion
o Cset exclude: kai@tp1.ruhr-uni-bochum.de|ChangeSet|20030217001132|22043
o KLIBC: fix up some type errors that were highlighted by the posix timer changes
o KLIBC: delete usr/root/hello
o klibc: add file support to gen_init_cpio.c
o klibc: fix up the hello_world example
Kai Germaschewski <kai-germaschewski@uiowa.edu>:
o klibc make clean
Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>:
o klibc: Move mounting of the root filesystem into userspace
o klibc: Silence too ambitious warnings
o klibc: Stop on error when building the CPIO
o klibc: Fix the "hello" example (for real)
o klibc: Fix a compiler warning
o kbuild/klibc: Integrate klibc into the build
o klibc: Merge klibc-0.77
-------------
Diffstat:
Makefile | 37
scripts/Makefile.build | 6
scripts/Makefile.clean | 11
scripts/Makefile.lib | 3
scripts/Makefile.user | 209 +
usr/Makefile | 40
usr/gen_init_cpio.c | 91
usr/lib/CAVEATS | 51
usr/lib/LICENSE | 73
usr/lib/MCONFIG | 48
usr/lib/Makefile | 141
usr/lib/README | 57
usr/lib/SOCKETCALLS | 21
usr/lib/SYSCALLS | 146
usr/lib/__shared_init.c | 56
usr/lib/__signal.c | 22
usr/lib/__static_init.c | 40
usr/lib/abort.c | 19
usr/lib/alarm.c | 29
usr/lib/arch/README | 67
usr/lib/arch/alpha/MCONFIG | 17
usr/lib/arch/alpha/Makefile.inc | 93
usr/lib/arch/alpha/README-gcc | 23
usr/lib/arch/alpha/crt0.S | 21
usr/lib/arch/alpha/divide.c | 57
usr/lib/arch/alpha/include/klibc/archsetjmp.h | 24
usr/lib/arch/alpha/include/klibc/archsys.h | 53
usr/lib/arch/alpha/include/machine/asm.h | 44
usr/lib/arch/alpha/pipe.c | 28
usr/lib/arch/alpha/setjmp.S | 61
usr/lib/arch/arm/MCONFIG | 26
usr/lib/arch/arm/Makefile.inc | 31
usr/lib/arch/arm/crt0.S | 25
usr/lib/arch/arm/include/klibc/archsetjmp.h | 14
usr/lib/arch/arm/include/klibc/archsys.h | 12
usr/lib/arch/arm/setjmp-arm.S | 40
usr/lib/arch/arm/setjmp-thumb.S | 58
usr/lib/arch/cris/MCONFIG | 11
usr/lib/arch/cris/Makefile.inc | 10
usr/lib/arch/cris/include/klibc/archsys.h | 12
usr/lib/arch/i386/MCONFIG | 24
usr/lib/arch/i386/Makefile.inc | 27
usr/lib/arch/i386/crt0.S | 33
usr/lib/arch/i386/exits.S | 45
usr/lib/arch/i386/include/klibc/archsetjmp.h | 19
usr/lib/arch/i386/include/klibc/archsys.h | 96
usr/lib/arch/i386/include/klibc/diverr.h | 16
usr/lib/arch/i386/libgcc/__ashldi3.S | 29
usr/lib/arch/i386/libgcc/__ashrdi3.S | 29
usr/lib/arch/i386/libgcc/__lshrdi3.S | 29
usr/lib/arch/i386/libgcc/__muldi3.S | 34
usr/lib/arch/i386/libgcc/__negdi2.S | 21
usr/lib/arch/i386/setjmp.S | 58
usr/lib/arch/i386/socketcall.S | 38
usr/lib/arch/ia64/MCONFIG | 11
usr/lib/arch/ia64/Makefile.inc | 10
usr/lib/arch/ia64/include/klibc/archsys.h | 12
usr/lib/arch/m68k/MCONFIG | 11
usr/lib/arch/m68k/Makefile.inc | 10
usr/lib/arch/m68k/include/klibc/archsys.h | 12
usr/lib/arch/mips/MCONFIG | 18
usr/lib/arch/mips/Makefile.inc | 24
usr/lib/arch/mips/crt0.S | 25
usr/lib/arch/mips/include/klibc/archsetjmp.h | 39
usr/lib/arch/mips/include/klibc/archsys.h | 12
usr/lib/arch/mips/include/machine/asm.h | 11
usr/lib/arch/mips/include/sgidefs.h | 20
usr/lib/arch/mips/pipe.S | 16
usr/lib/arch/mips/setjmp.S | 82
usr/lib/arch/mips/vfork.S | 19
usr/lib/arch/mips64/MCONFIG | 11
usr/lib/arch/mips64/Makefile.inc | 10
usr/lib/arch/mips64/include/klibc/archsys.h | 12
usr/lib/arch/parisc/MCONFIG | 11
usr/lib/arch/parisc/Makefile.inc | 10
usr/lib/arch/parisc/include/klibc/archsys.h | 12
usr/lib/arch/ppc/MCONFIG | 11
usr/lib/arch/ppc/Makefile.inc | 15
usr/lib/arch/ppc/crt0.S | 29
usr/lib/arch/ppc/include/klibc/archsetjmp.h | 36
usr/lib/arch/ppc/include/klibc/archsys.h | 55
usr/lib/arch/ppc/setjmp.S | 35
usr/lib/arch/ppc64/MCONFIG | 11
usr/lib/arch/ppc64/Makefile.inc | 10
usr/lib/arch/ppc64/crt0.S | 38
usr/lib/arch/ppc64/include/klibc/archsys.h | 52
usr/lib/arch/s390/MCONFIG | 13
usr/lib/arch/s390/Makefile.inc | 16
usr/lib/arch/s390/crt0.S | 25
usr/lib/arch/s390/include/klibc/archsetjmp.h | 15
usr/lib/arch/s390/include/klibc/archsys.h | 41
usr/lib/arch/s390/setjmp.S | 32
usr/lib/arch/s390x/MCONFIG | 13
usr/lib/arch/s390x/Makefile.inc | 16
usr/lib/arch/s390x/crt0.S | 21
usr/lib/arch/s390x/include/klibc/archsetjmp.h | 15
usr/lib/arch/s390x/include/klibc/archsys.h | 41
usr/lib/arch/s390x/setjmp.S | 36
usr/lib/arch/sh/MCONFIG | 11
usr/lib/arch/sh/Makefile.inc | 10
usr/lib/arch/sh/include/klibc/archsys.h | 12
usr/lib/arch/sparc/MCONFIG | 18
usr/lib/arch/sparc/Makefile.inc | 44
usr/lib/arch/sparc/crt0.S | 2
usr/lib/arch/sparc/crt0i.S | 100
usr/lib/arch/sparc/divrem.m4 | 276 +
usr/lib/arch/sparc/include/klibc/archsetjmp.h | 16
usr/lib/arch/sparc/include/klibc/archsys.h | 65
usr/lib/arch/sparc/include/machine/asm.h | 192 +
usr/lib/arch/sparc/include/machine/frame.h | 138
usr/lib/arch/sparc/include/machine/trap.h | 141
usr/lib/arch/sparc/setjmp.S | 38
usr/lib/arch/sparc/smul.S | 160
usr/lib/arch/sparc/umul.S | 193 +
usr/lib/arch/sparc64/MCONFIG | 21
usr/lib/arch/sparc64/Makefile.inc | 13
usr/lib/arch/sparc64/crt0.S | 2
usr/lib/arch/sparc64/include/klibc/archsetjmp.h | 16
usr/lib/arch/sparc64/include/klibc/archsys.h | 157
usr/lib/arch/sparc64/setjmp.S | 55
usr/lib/arch/x86_64/MCONFIG | 16
usr/lib/arch/x86_64/Makefile.inc | 16
usr/lib/arch/x86_64/crt0.S | 22
usr/lib/arch/x86_64/exits.S | 35
usr/lib/arch/x86_64/include/klibc/archsetjmp.h | 21
usr/lib/arch/x86_64/include/klibc/archsys.h | 32
usr/lib/arch/x86_64/setjmp.S | 54
usr/lib/assert.c | 13
usr/lib/atexit.c | 10
usr/lib/atexit.h | 19
usr/lib/atoi.c | 3
usr/lib/atol.c | 3
usr/lib/atoll.c | 3
usr/lib/atox.c | 14
usr/lib/brk.c | 24
usr/lib/bsd_signal.c | 11
usr/lib/calloc.c | 21
usr/lib/closelog.c | 18
usr/lib/creat.c | 12
usr/lib/ctypes.c | 281 +
usr/lib/exec_l.c | 57
usr/lib/execl.c | 8
usr/lib/execle.c | 8
usr/lib/execlp.c | 8
usr/lib/execlpe.c | 8
usr/lib/execv.c | 13
usr/lib/execvp.c | 13
usr/lib/execvpe.c | 73
usr/lib/exitc.c | 36
usr/lib/fdatasync.c | 15
usr/lib/fgetc.c | 20
usr/lib/fgets.c | 33
usr/lib/fopen.c | 46
usr/lib/fork.c | 29
usr/lib/fprintf.c | 19
usr/lib/fputc.c | 14
usr/lib/fputs.c | 15
usr/lib/fread.c | 35
usr/lib/fread2.c | 13
usr/lib/fwrite.c | 35
usr/lib/fwrite2.c | 13
usr/lib/getcwd.c | 15
usr/lib/getdomainname.c | 25
usr/lib/getenv.c | 22
usr/lib/gethostname.c | 25
usr/lib/getopt.c | 74
usr/lib/getpriority.c | 25
usr/lib/globals.c | 10
usr/lib/include/alloca.h | 13
usr/lib/include/arpa/inet.h | 24
usr/lib/include/assert.h | 22
usr/lib/include/bits32/bitsize/limits.h | 14
usr/lib/include/bits32/bitsize/stddef.h | 18
usr/lib/include/bits32/bitsize/stdint.h | 34
usr/lib/include/bits32/bitsize/stdintconst.h | 18
usr/lib/include/bits32/bitsize/stdintlimits.h | 22
usr/lib/include/bits64/bitsize/limits.h | 14
usr/lib/include/bits64/bitsize/stddef.h | 13
usr/lib/include/bits64/bitsize/stdint.h | 36
usr/lib/include/bits64/bitsize/stdintconst.h | 18
usr/lib/include/bits64/bitsize/stdintlimits.h | 22
usr/lib/include/ctype.h | 117
usr/lib/include/dirent.h | 20
usr/lib/include/elf.h | 12
usr/lib/include/endian.h | 41
usr/lib/include/errno.h | 8
usr/lib/include/fcntl.h | 11
usr/lib/include/grp.h | 13
usr/lib/include/inttypes.h | 226 +
usr/lib/include/klibc/compiler.h | 61
usr/lib/include/klibc/diverr.h | 16
usr/lib/include/klibc/extern.h | 14
usr/lib/include/limits.h | 40
usr/lib/include/net/if.h | 1
usr/lib/include/net/if_arp.h | 1
usr/lib/include/net/if_ether.h | 1
usr/lib/include/net/if_packet.h | 1
usr/lib/include/netinet/in.h | 29
usr/lib/include/netinet/in6.h | 10
usr/lib/include/netinet/ip.h | 13
usr/lib/include/netinet/tcp.h | 11
usr/lib/include/netinet/udp.h | 19
usr/lib/include/poll.h | 16
usr/lib/include/sched.h | 23
usr/lib/include/setjmp.h | 43
usr/lib/include/signal.h | 72
usr/lib/include/stdarg.h | 14
usr/lib/include/stddef.h | 24
usr/lib/include/stdint.h | 113
usr/lib/include/stdio.h | 109
usr/lib/include/stdlib.h | 94
usr/lib/include/string.h | 37
usr/lib/include/sys/dirent.h | 13
usr/lib/include/sys/fsuid.h | 14
usr/lib/include/sys/ioctl.h | 14
usr/lib/include/sys/klog.h | 24
usr/lib/include/sys/mman.h | 21
usr/lib/include/sys/module.h | 158
usr/lib/include/sys/mount.h | 55
usr/lib/include/sys/param.h | 11
usr/lib/include/sys/reboot.h | 25
usr/lib/include/sys/resource.h | 15
usr/lib/include/sys/select.h | 13
usr/lib/include/sys/socket.h | 50
usr/lib/include/sys/socketcalls.h | 28
usr/lib/include/sys/stat.h | 23
usr/lib/include/sys/syscall.h | 15
usr/lib/include/sys/time.h | 16
usr/lib/include/sys/times.h | 14
usr/lib/include/sys/types.h | 127
usr/lib/include/sys/uio.h | 15
usr/lib/include/sys/utime.h | 10
usr/lib/include/sys/utsname.h | 23
usr/lib/include/sys/vfs.h | 14
usr/lib/include/sys/wait.h | 19
usr/lib/include/syslog.h | 53
usr/lib/include/termios.h | 86
usr/lib/include/time.h | 14
usr/lib/include/unistd.h | 106
usr/lib/include/utime.h | 15
usr/lib/inet/inet_addr.c | 14
usr/lib/inet/inet_aton.c | 23
usr/lib/inet/inet_ntoa.c | 19
usr/lib/inet/inet_ntop.c | 52
usr/lib/inet/inet_pton.c | 74
usr/lib/interp.S | 11
usr/lib/isatty.c | 21
usr/lib/libgcc/__divdi3.c | 29
usr/lib/libgcc/__divsi3.c | 29
usr/lib/libgcc/__moddi3.c | 29
usr/lib/libgcc/__modsi3.c | 29
usr/lib/libgcc/__udivdi3.c | 13
usr/lib/libgcc/__udivmoddi4.c | 32
usr/lib/libgcc/__udivmodsi4.c | 32
usr/lib/libgcc/__udivsi3.c | 13
usr/lib/libgcc/__umoddi3.c | 16
usr/lib/libgcc/__umodsi3.c | 16
usr/lib/llseek.c | 34
usr/lib/lrand48.c | 42
usr/lib/makeerrlist.pl | 80
usr/lib/malloc.c | 192 +
usr/lib/malloc.h | 51
usr/lib/memccpy.c | 23
usr/lib/memchr.c | 18
usr/lib/memcmp.c | 19
usr/lib/memcpy.c | 29
usr/lib/memmem.c | 44
usr/lib/memmove.c | 34
usr/lib/memset.c | 30
usr/lib/memswap.c | 23
usr/lib/mmap.c | 51
usr/lib/nice.c | 22
usr/lib/onexit.c | 39
usr/lib/pause.c | 21
usr/lib/perror.c | 12
usr/lib/printf.c | 19
usr/lib/pty.c | 31
usr/lib/puts.c | 13
usr/lib/qsort.c | 42
usr/lib/raise.c | 11
usr/lib/readdir.c | 66
usr/lib/realloc.c | 49
usr/lib/reboot.c | 15
usr/lib/recv.c | 11
usr/lib/sbrk.c | 23
usr/lib/seed48.c | 19
usr/lib/select.c | 9
usr/lib/send.c | 11
usr/lib/setegid.c | 10
usr/lib/setenv.c | 124
usr/lib/seteuid.c | 10
usr/lib/setpgrp.c | 10
usr/lib/setresgid.c | 29
usr/lib/setresuid.c | 30
usr/lib/sha1hash.c | 317 +
usr/lib/sigaction.c | 19
usr/lib/siglist.c | 115
usr/lib/siglongjmp.c | 16
usr/lib/signal.c | 11
usr/lib/sigpending.c | 19
usr/lib/sigprocmask.c | 19
usr/lib/sigsuspend.c | 19
usr/lib/sleep.c | 20
usr/lib/snprintf.c | 16
usr/lib/socketcalls.pl | 67
usr/lib/socketcalls/socketcommon.h | 25
usr/lib/sprintf.c | 18
usr/lib/srand48.c | 16
usr/lib/sscanf.c | 17
usr/lib/strcat.c | 11
usr/lib/strchr.c | 16
usr/lib/strcmp.c | 20
usr/lib/strcpy.c | 20
usr/lib/strdup.c | 17
usr/lib/strerror.c | 25
usr/lib/strlen.c | 14
usr/lib/strncat.c | 11
usr/lib/strncmp.c | 20
usr/lib/strncpy.c | 22
usr/lib/strntoimax.c | 13
usr/lib/strntoumax.c | 75
usr/lib/strrchr.c | 18
usr/lib/strsep.c | 21
usr/lib/strspn.c | 67
usr/lib/strstr.c | 10
usr/lib/strtoimax.c | 3
usr/lib/strtok.c | 16
usr/lib/strtol.c | 3
usr/lib/strtoll.c | 3
usr/lib/strtoul.c | 3
usr/lib/strtoull.c | 3
usr/lib/strtoumax.c | 3
usr/lib/strtox.c | 13
usr/lib/syscalls.pl | 78
usr/lib/syscalls/syscommon.h | 29
usr/lib/syslog.c | 68
usr/lib/tests/getenvtest.c | 26
usr/lib/tests/getopttest.c | 31
usr/lib/tests/hello.c | 7
usr/lib/tests/idtest.c | 14
usr/lib/tests/malloctest.c | 4145 ++++++++++++++++++++++++
usr/lib/tests/memstrtest.c | 29
usr/lib/tests/microhello.c | 9
usr/lib/tests/minihello.c | 7
usr/lib/tests/minips.c | 452 ++
usr/lib/tests/nfs_no_rpc.c | 538 +++
usr/lib/tests/setjmptest.c | 36
usr/lib/tests/testrand48.c | 19
usr/lib/tests/testvsnp.c | 115
usr/lib/time.c | 27
usr/lib/umount.c | 12
usr/lib/unsetenv.c | 40
usr/lib/usleep.c | 15
usr/lib/utime.c | 30
usr/lib/vfprintf.c | 26
usr/lib/vprintf.c | 11
usr/lib/vsnprintf.c | 433 ++
usr/lib/vsprintf.c | 11
usr/lib/vsscanf.c | 365 ++
usr/lib/wait.c | 12
usr/lib/wait3.c | 12
usr/lib/waitpid.c | 12
usr/root/Makefile | 3
usr/root/hello.c | 13
364 files changed, 18288 insertions(+), 9 deletions(-)
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 0:16 [BK PATCH] klibc for 2.5.64 - try 2 Greg KH
@ 2003-03-07 1:02 ` Roman Zippel
2003-03-07 1:05 ` H. Peter Anvin
0 siblings, 1 reply; 63+ messages in thread
From: Roman Zippel @ 2003-03-07 1:02 UTC (permalink / raw)
To: Greg KH; +Cc: Linus Torvalds, hpa, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 1:02 ` Roman Zippel
@ 2003-03-07 1:05 ` H. Peter Anvin
2003-03-07 1:23 ` Roman Zippel
0 siblings, 1 reply; 63+ messages in thread
From: H. Peter Anvin @ 2003-03-07 1:05 UTC (permalink / raw)
To: Roman Zippel; +Cc: Greg KH, Linus Torvalds, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 1:05 ` H. Peter Anvin
@ 2003-03-07 1:23 ` Roman Zippel
2003-03-07 1:35 ` H. Peter Anvin
0 siblings, 1 reply; 63+ messages in thread
From: Roman Zippel @ 2003-03-07 1:23 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Greg KH, Linus Torvalds, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 1:23 ` Roman Zippel
@ 2003-03-07 1:35 ` H. Peter Anvin
2003-03-07 9:55 ` Roman Zippel
0 siblings, 1 reply; 63+ messages in thread
From: H. Peter Anvin @ 2003-03-07 1:35 UTC (permalink / raw)
To: Roman Zippel; +Cc: Greg KH, Linus Torvalds, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 1:35 ` H. Peter Anvin
@ 2003-03-07 9:55 ` Roman Zippel
2003-03-07 13:43 ` H. Peter Anvin
0 siblings, 1 reply; 63+ messages in thread
From: Roman Zippel @ 2003-03-07 9:55 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Greg KH, Linus Torvalds, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 9:55 ` Roman Zippel
@ 2003-03-07 13:43 ` H. Peter Anvin
2003-03-07 15:33 ` Kai Germaschewski
2003-03-07 18:37 ` Roman Zippel
0 siblings, 2 replies; 63+ messages in thread
From: H. Peter Anvin @ 2003-03-07 13:43 UTC (permalink / raw)
To: Roman Zippel; +Cc: Greg KH, Linus Torvalds, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 13:43 ` H. Peter Anvin
@ 2003-03-07 15:33 ` Kai Germaschewski
2003-03-07 19:42 ` H. Peter Anvin
2003-03-07 18:37 ` Roman Zippel
1 sibling, 1 reply; 63+ messages in thread
From: Kai Germaschewski @ 2003-03-07 15:33 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Roman Zippel, Greg KH, Linus Torvalds, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 15:33 ` Kai Germaschewski
@ 2003-03-07 19:42 ` H. Peter Anvin
0 siblings, 0 replies; 63+ messages in thread
From: H. Peter Anvin @ 2003-03-07 19:42 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Roman Zippel, Greg KH, Linus Torvalds, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 13:43 ` H. Peter Anvin
2003-03-07 15:33 ` Kai Germaschewski
@ 2003-03-07 18:37 ` Roman Zippel
2003-03-07 18:52 ` Linus Torvalds
1 sibling, 1 reply; 63+ messages in thread
From: Roman Zippel @ 2003-03-07 18:37 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Greg KH, Linus Torvalds, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 18:37 ` Roman Zippel
@ 2003-03-07 18:52 ` Linus Torvalds
2003-03-07 21:55 ` Roman Zippel
0 siblings, 1 reply; 63+ messages in thread
From: Linus Torvalds @ 2003-03-07 18:52 UTC (permalink / raw)
To: Roman Zippel; +Cc: H. Peter Anvin, Greg KH, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 18:52 ` Linus Torvalds
@ 2003-03-07 21:55 ` Roman Zippel
2003-03-07 23:05 ` Linus Torvalds
0 siblings, 1 reply; 63+ messages in thread
From: Roman Zippel @ 2003-03-07 21:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Greg KH, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 21:55 ` Roman Zippel
@ 2003-03-07 23:05 ` Linus Torvalds
2003-03-07 23:36 ` Greg KH
2003-03-07 23:39 ` Russell King
0 siblings, 2 replies; 63+ messages in thread
From: Linus Torvalds @ 2003-03-07 23:05 UTC (permalink / raw)
To: Roman Zippel; +Cc: H. Peter Anvin, Greg KH, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 23:05 ` Linus Torvalds
@ 2003-03-07 23:36 ` Greg KH
2003-03-07 23:53 ` Linus Torvalds
2003-03-07 23:39 ` Russell King
1 sibling, 1 reply; 63+ messages in thread
From: Greg KH @ 2003-03-07 23:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 23:36 ` Greg KH
@ 2003-03-07 23:53 ` Linus Torvalds
2003-03-07 23:55 ` Greg KH
0 siblings, 1 reply; 63+ messages in thread
From: Linus Torvalds @ 2003-03-07 23:53 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 23:53 ` Linus Torvalds
@ 2003-03-07 23:55 ` Greg KH
2003-03-08 0:47 ` Linus Torvalds
0 siblings, 1 reply; 63+ messages in thread
From: Greg KH @ 2003-03-07 23:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 23:55 ` Greg KH
@ 2003-03-08 0:47 ` Linus Torvalds
2003-03-08 0:54 ` Greg KH
0 siblings, 1 reply; 63+ messages in thread
From: Linus Torvalds @ 2003-03-08 0:47 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 0:47 ` Linus Torvalds
@ 2003-03-08 0:54 ` Greg KH
0 siblings, 0 replies; 63+ messages in thread
From: Greg KH @ 2003-03-08 0:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 23:05 ` Linus Torvalds
2003-03-07 23:36 ` Greg KH
@ 2003-03-07 23:39 ` Russell King
2003-03-07 23:44 ` H. Peter Anvin
2003-03-08 2:06 ` Eric W. Biederman
1 sibling, 2 replies; 63+ messages in thread
From: Russell King @ 2003-03-07 23:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, H. Peter Anvin, Greg KH, linux-kernel
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 (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 23:39 ` Russell King
@ 2003-03-07 23:44 ` H. Peter Anvin
2003-03-08 0:00 ` Russell King
2003-03-08 0:38 ` Roman Zippel
2003-03-08 2:06 ` Eric W. Biederman
1 sibling, 2 replies; 63+ messages in thread
From: H. Peter Anvin @ 2003-03-07 23:44 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Roman Zippel, Greg KH, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 23:44 ` H. Peter Anvin
@ 2003-03-08 0:00 ` Russell King
2003-03-08 0:38 ` Roman Zippel
1 sibling, 0 replies; 63+ messages in thread
From: Russell King @ 2003-03-08 0:00 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Roman Zippel, Greg KH, linux-kernel
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 (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 23:44 ` H. Peter Anvin
2003-03-08 0:00 ` Russell King
@ 2003-03-08 0:38 ` Roman Zippel
2003-03-08 0:46 ` H. Peter Anvin
2003-03-08 0:46 ` David Lang
1 sibling, 2 replies; 63+ messages in thread
From: Roman Zippel @ 2003-03-08 0:38 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Russell King, Linus Torvalds, Greg KH, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 0:38 ` Roman Zippel
@ 2003-03-08 0:46 ` H. Peter Anvin
2003-03-08 1:27 ` Roman Zippel
2003-03-08 0:46 ` David Lang
1 sibling, 1 reply; 63+ messages in thread
From: H. Peter Anvin @ 2003-03-08 0:46 UTC (permalink / raw)
To: Roman Zippel; +Cc: Russell King, Linus Torvalds, Greg KH, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 0:46 ` H. Peter Anvin
@ 2003-03-08 1:27 ` Roman Zippel
2003-03-12 17:27 ` Pavel Machek
0 siblings, 1 reply; 63+ messages in thread
From: Roman Zippel @ 2003-03-08 1:27 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Russell King, Linus Torvalds, Greg KH, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 1:27 ` Roman Zippel
@ 2003-03-12 17:27 ` Pavel Machek
2003-03-13 0:22 ` H. Peter Anvin
0 siblings, 1 reply; 63+ messages in thread
From: Pavel Machek @ 2003-03-12 17:27 UTC (permalink / raw)
To: Roman Zippel
Cc: H. Peter Anvin, Russell King, Linus Torvalds, Greg KH, linux-kernel
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...
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-12 17:27 ` Pavel Machek
@ 2003-03-13 0:22 ` H. Peter Anvin
0 siblings, 0 replies; 63+ messages in thread
From: H. Peter Anvin @ 2003-03-13 0:22 UTC (permalink / raw)
To: Pavel Machek
Cc: Roman Zippel, Russell King, Linus Torvalds, Greg KH, linux-kernel
Pavel Machek wrote:
>
> I believe HPA wants klibc to stay small,
> and BSD license will act as contribution-
> stopper, therefore keeping it small...
>
Heh,
Although that may be a beneficial side effect :) the real reason is the
one Linus articulated:
> 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.
-hpa
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 0:38 ` Roman Zippel
2003-03-08 0:46 ` H. Peter Anvin
@ 2003-03-08 0:46 ` David Lang
2003-03-08 1:49 ` Roman Zippel
1 sibling, 1 reply; 63+ messages in thread
From: David Lang @ 2003-03-08 0:46 UTC (permalink / raw)
To: Roman Zippel
Cc: H. Peter Anvin, Russell King, Linus Torvalds, Greg KH, linux-kernel
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 <zippel@linux-m68k.org>
> To: H. Peter Anvin <hpa@zytor.com>
> Cc: Russell King <rmk@arm.linux.org.uk>,
> Linus Torvalds <torvalds@transmeta.com>, Greg KH <greg@kroah.com>,
> linux-kernel@vger.kernel.org
> 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 0:46 ` David Lang
@ 2003-03-08 1:49 ` Roman Zippel
2003-03-08 2:00 ` David Lang
0 siblings, 1 reply; 63+ messages in thread
From: Roman Zippel @ 2003-03-08 1:49 UTC (permalink / raw)
To: David Lang
Cc: H. Peter Anvin, Russell King, Linus Torvalds, Greg KH, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 1:49 ` Roman Zippel
@ 2003-03-08 2:00 ` David Lang
2003-03-08 2:26 ` Roman Zippel
2003-03-08 16:55 ` Roman Zippel
0 siblings, 2 replies; 63+ messages in thread
From: David Lang @ 2003-03-08 2:00 UTC (permalink / raw)
To: Roman Zippel
Cc: H. Peter Anvin, Russell King, Linus Torvalds, Greg KH, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 2:00 ` David Lang
@ 2003-03-08 2:26 ` Roman Zippel
2003-03-08 16:55 ` Roman Zippel
1 sibling, 0 replies; 63+ messages in thread
From: Roman Zippel @ 2003-03-08 2:26 UTC (permalink / raw)
To: David Lang
Cc: H. Peter Anvin, Russell King, Linus Torvalds, Greg KH, linux-kernel
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.
Using it and including it into the kernel source are still two different
things. Why should we allow the precedent and create such a license mess?
The problem is easy to ignore now, but it will possibly hunt us forever.
> 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.
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.
bye, Roman
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 2:00 ` David Lang
2003-03-08 2:26 ` Roman Zippel
@ 2003-03-08 16:55 ` Roman Zippel
2003-03-08 17:06 ` Vlad@geekizoid.com
1 sibling, 1 reply; 63+ messages in thread
From: Roman Zippel @ 2003-03-08 16:55 UTC (permalink / raw)
To: David Lang
Cc: H. Peter Anvin, Russell King, Linus Torvalds, Greg KH, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 16:55 ` Roman Zippel
@ 2003-03-08 17:06 ` Vlad@geekizoid.com
0 siblings, 0 replies; 63+ messages in thread
From: Vlad@geekizoid.com @ 2003-03-08 17:06 UTC (permalink / raw)
To: 'Roman Zippel'
Cc: 'H. Peter Anvin', 'Russell King',
'Linus Torvalds', 'Greg KH',
linux-kernel, 'David Lang'
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]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;
> linux-kernel@vger.kernel.org
> 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 / info@lrsehosting.com
X AGAINST HTML MAIL / http://www.lrsehosting.com/
/ \ AND POSTINGS / vlad@lrsehosting.com
-------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 23:39 ` Russell King
2003-03-07 23:44 ` H. Peter Anvin
@ 2003-03-08 2:06 ` Eric W. Biederman
[not found] ` <20030308100359.A27153@flint.arm.linux.org.uk>
1 sibling, 1 reply; 63+ messages in thread
From: Eric W. Biederman @ 2003-03-08 2:06 UTC (permalink / raw)
To: Russell King
Cc: Linus Torvalds, Roman Zippel, H. Peter Anvin, Greg KH, linux-kernel
Russell King <rmk@arm.linux.org.uk> 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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
@ 2003-03-07 19:21 Matthew Wilcox
2003-03-07 21:04 ` Alan Cox
0 siblings, 1 reply; 63+ messages in thread
From: Matthew Wilcox @ 2003-03-07 19:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
> 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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-07 19:21 Matthew Wilcox
@ 2003-03-07 21:04 ` Alan Cox
0 siblings, 0 replies; 63+ messages in thread
From: Alan Cox @ 2003-03-07 21:04 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Linus Torvalds, Linux Kernel Mailing List
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 ;)
^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <1047106664.22024.0.camel@rth.ninka.net>]
* Re: [BK PATCH] klibc for 2.5.64 - try 2
[not found] <1047106664.22024.0.camel@rth.ninka.net>
@ 2003-03-08 15:54 ` Linus Torvalds
2003-03-08 16:03 ` David S. Miller
0 siblings, 1 reply; 63+ messages in thread
From: Linus Torvalds @ 2003-03-08 15:54 UTC (permalink / raw)
To: David S. Miller
Cc: Roman Zippel, David Lang, H. Peter Anvin, Russell King, Greg KH,
linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 15:54 ` Linus Torvalds
@ 2003-03-08 16:03 ` David S. Miller
2003-03-08 16:35 ` Linus Torvalds
0 siblings, 1 reply; 63+ messages in thread
From: David S. Miller @ 2003-03-08 16:03 UTC (permalink / raw)
To: torvalds; +Cc: zippel, david.lang, hpa, rmk, greg, linux-kernel
From: Linus Torvalds <torvalds@transmeta.com>
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.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 16:03 ` David S. Miller
@ 2003-03-08 16:35 ` Linus Torvalds
2003-03-08 16:22 ` David S. Miller
` (3 more replies)
0 siblings, 4 replies; 63+ messages in thread
From: Linus Torvalds @ 2003-03-08 16:35 UTC (permalink / raw)
To: David S. Miller; +Cc: zippel, david.lang, hpa, rmk, greg, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 16:35 ` Linus Torvalds
@ 2003-03-08 16:22 ` David S. Miller
2003-03-08 17:07 ` Larry McVoy
` (2 subsequent siblings)
3 siblings, 0 replies; 63+ messages in thread
From: David S. Miller @ 2003-03-08 16:22 UTC (permalink / raw)
To: torvalds; +Cc: zippel, david.lang, hpa, rmk, greg, linux-kernel
From: Linus Torvalds <torvalds@transmeta.com>
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.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 16:35 ` Linus Torvalds
2003-03-08 16:22 ` David S. Miller
@ 2003-03-08 17:07 ` Larry McVoy
2003-03-08 20:22 ` Linus Torvalds
2003-03-08 21:02 ` H. Peter Anvin
2003-03-08 20:56 ` H. Peter Anvin
2003-03-09 1:24 ` Roman Zippel
3 siblings, 2 replies; 63+ messages in thread
From: Larry McVoy @ 2003-03-08 17:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: David S. Miller, zippel, david.lang, hpa, rmk, greg, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 17:07 ` Larry McVoy
@ 2003-03-08 20:22 ` Linus Torvalds
2003-03-08 21:02 ` H. Peter Anvin
1 sibling, 0 replies; 63+ messages in thread
From: Linus Torvalds @ 2003-03-08 20:22 UTC (permalink / raw)
To: Larry McVoy
Cc: David S. Miller, zippel, david.lang, hpa, rmk, greg, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 17:07 ` Larry McVoy
2003-03-08 20:22 ` Linus Torvalds
@ 2003-03-08 21:02 ` H. Peter Anvin
1 sibling, 0 replies; 63+ messages in thread
From: H. Peter Anvin @ 2003-03-08 21:02 UTC (permalink / raw)
To: linux-kernel
Followup to: <20030308170741.GB29789@work.bitmover.com>
By author: Larry McVoy <lm@bitmover.com>
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
--
<hpa@transmeta.com> at work, <hpa@zytor.com> 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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 16:35 ` Linus Torvalds
2003-03-08 16:22 ` David S. Miller
2003-03-08 17:07 ` Larry McVoy
@ 2003-03-08 20:56 ` H. Peter Anvin
2003-03-09 1:24 ` Roman Zippel
3 siblings, 0 replies; 63+ messages in thread
From: H. Peter Anvin @ 2003-03-08 20:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: David S. Miller, zippel, david.lang, rmk, greg, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [BK PATCH] klibc for 2.5.64 - try 2
2003-03-08 16:35 ` Linus Torvalds
` (2 preceding siblings ...)
2003-03-08 20:56 ` H. Peter Anvin
@ 2003-03-09 1:24 ` Roman Zippel
3 siblings, 0 replies; 63+ messages in thread
From: Roman Zippel @ 2003-03-09 1:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David S. Miller, david.lang, hpa, rmk, greg, linux-kernel
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
^ permalink raw reply [flat|nested] 63+ messages in thread
end of thread, other threads:[~2003-03-13 0:12 UTC | newest]
Thread overview: 63+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-07 0:16 [BK PATCH] klibc for 2.5.64 - try 2 Greg KH
2003-03-07 1:02 ` Roman Zippel
2003-03-07 1:05 ` H. Peter Anvin
2003-03-07 1:23 ` Roman Zippel
2003-03-07 1:35 ` H. Peter Anvin
2003-03-07 9:55 ` Roman Zippel
2003-03-07 13:43 ` H. Peter Anvin
2003-03-07 15:33 ` Kai Germaschewski
2003-03-07 19:42 ` H. Peter Anvin
2003-03-07 18:37 ` Roman Zippel
2003-03-07 18:52 ` Linus Torvalds
2003-03-07 21:55 ` Roman Zippel
2003-03-07 23:05 ` Linus Torvalds
2003-03-07 23:36 ` Greg KH
2003-03-07 23:53 ` Linus Torvalds
2003-03-07 23:55 ` Greg KH
2003-03-08 0:47 ` Linus Torvalds
2003-03-08 0:54 ` Greg KH
2003-03-07 23:39 ` Russell King
2003-03-07 23:44 ` H. Peter Anvin
2003-03-08 0:00 ` Russell King
2003-03-08 0:38 ` Roman Zippel
2003-03-08 0:46 ` H. Peter Anvin
2003-03-08 1:27 ` Roman Zippel
2003-03-12 17:27 ` Pavel Machek
2003-03-13 0:22 ` H. Peter Anvin
2003-03-08 0:46 ` David Lang
2003-03-08 1:49 ` Roman Zippel
2003-03-08 2:00 ` David Lang
2003-03-08 2:26 ` Roman Zippel
2003-03-08 16:55 ` Roman Zippel
2003-03-08 17:06 ` Vlad@geekizoid.com
2003-03-08 2:06 ` Eric W. Biederman
[not found] ` <20030308100359.A27153@flint.arm.linux.org.uk>
2003-03-08 15:50 ` Eric W. Biederman
2003-03-08 16:13 ` Russell King
2003-03-08 17:28 ` Eric W. Biederman
2003-03-08 21:08 ` H. Peter Anvin
2003-03-09 2:25 ` Eric W. Biederman
2003-03-09 2:30 ` Larry McVoy
2003-03-09 11:32 ` Daniel Egger
2003-03-09 11:46 ` Eric W. Biederman
2003-03-09 14:19 ` Daniel Egger
2003-03-10 0:49 ` H. Peter Anvin
2003-03-10 1:40 ` Daniel Egger
2003-03-10 6:01 ` Eric W. Biederman
2003-03-10 20:33 ` Hans-Peter Jansen
2003-03-10 22:02 ` Daniel Egger
2003-03-08 20:52 ` H. Peter Anvin
2003-03-08 21:10 ` H. Peter Anvin
2003-03-09 1:29 ` Eric W. Biederman
2003-03-09 1:46 ` H. Peter Anvin
2003-03-09 2:37 ` Eric W. Biederman
2003-03-07 19:21 Matthew Wilcox
2003-03-07 21:04 ` Alan Cox
[not found] <1047106664.22024.0.camel@rth.ninka.net>
2003-03-08 15:54 ` Linus Torvalds
2003-03-08 16:03 ` David S. Miller
2003-03-08 16:35 ` Linus Torvalds
2003-03-08 16:22 ` David S. Miller
2003-03-08 17:07 ` Larry McVoy
2003-03-08 20:22 ` Linus Torvalds
2003-03-08 21:02 ` H. Peter Anvin
2003-03-08 20:56 ` H. Peter Anvin
2003-03-09 1:24 ` Roman Zippel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).