[BusyBox] RFC: Cutting a BusyBox release today
Erik Andersen
andersen at lineo.com
Wed Jun 21 21:00:11 UTC 2000
On Wed Jun 21, 2000 at 04:10:54PM -0400, Pavel Roskin wrote:
> Hello, Erik!
>
> > Anybody have any objections to my cutting a real BusyBox release today? I was
> > thinking that it is about time (well, ok I admit it is _way_ past time).
>
> Wait a minute. There are some issues.
>
> Busybox doesn't compile with headers from Linux-2.4.0-test1 due to
> problems with linux/fs.h (observed on Mandrake 6.0 with pgcc-1.1.3-3mdk
> and glibc-2.1.1-9mdk):
>
> gcc -Wall -Os -fomit-frame-pointer -fno-builtin -D_GNU_SOURCE
> -DBB_VER='"0.44"' -DBB_BT='"
> 2000.06.21-20:06+0000"' -c freeramdisk.c -o freeramdisk.o
> In file included from /usr/include/linux/dcache.h:5,
> from /usr/include/linux/fs.h:19,
> from freeramdisk.c:26:
> /usr/include/linux/mount.h:16: parse error before `kdev_t'
> /usr/include/linux/mount.h:16: warning: no semicolon at end of struct or
> union
> /usr/include/linux/mount.h:21: parse error before `}'
> make: *** [freeramdisk.o] Error 1
I know for a fact that BusyBox (as currently constituted) will not work with
the 2.4.x kernels. I know of the following problems:
1) The sysinfo syscall has changed what it does (binary incompatable), breaking
init and free.
2) BusyBox NFS support is broken with 2.4.x (needs to be adjusted for NFSv3 and
kernel header changes).
3) mount,umount,and df are all broken by the "none" entries for fake filesystems
such as the shared mem one. Al Viro claims these will be disappearing soon...
I made a kernel patch that reverts the sysinfo changes (a temporary bandaid),
and I have been fighting with Alan Cox an a way to resolve these changes in a
binary compatable way, but Alan has not been very receptive. I was planning on
appealing to Linus (when he gets back from vacation) and then going with
whatever he decides...
So my thought is, 2.4.x just isn't ready for BusyBox to target it, and even if
it was, BusyBox isn't ready yet either. Seems to me like this will not be
ready for a while, and we should just not worry about it yet.
As long as I have BB_FEATURE_NFSMOUNT turned off, everything compiles cleanly
for me with linux2.4.0test1-ac22-riel (i.e. I don't see the freeramdisk.c
problem you reported). I use Debian potato (gcc 2.95.2, GNU libc 2.1.3).
Of course, as noted above, compiling != working.
> math was renamed to dc without changing some stuff. The error messages
> still refer to math. We need to go through all occurences of "math"
Thx. When John Beppu asked about renaming it the more POSIX-ly correct
dc, I asked him to clean that stuff up. Guess he missed some spots.
Thanks for checking.
> busybox.pod doesn't even mention e.g. insmod
I'm seriously thinking that we need to switch to a literate programming style
so that docs are autogenerated form the source. Definately a TODO item for the
next release.
For this release, I just whipped toget a bit of shell script to figure out what
is missing from the docs. Turn out 'insmod' and 'telnet' are needed. I will
get those. Could you document the rm/ln "--" behavior you recently fixed up?
-Erik
--
Erik B. Andersen email: andersen at lineo.com
--This message was written using 73% post-consumer electrons--
More information about the busybox
mailing list