Version 1.1.1 on Tuesday.

[Rob Landley]

The darn mount rewrite rewrite (that duplication is not a typo, this is a 
rewrite of the rewrite I did last year) is in and tested, along with my test 
suite.  How did I run that test suite?  Here's the quick-and-dirty version:

Download the latest linux kernel, grab the attached mini.config and save it as 
"allno.config" in the kernel directory, "make ARCH=um allnoconfig", "make 
ARCH=um", and you have a User Mode Linux binary.  

Yeah, I know that's ugly:
  http://lwn.net/Articles/160497/
  http://lwn.net/Articles/161086/

That's on my short list of features to add to busybox.  (make miniconfig, make 
standalone, bbsh, a rewritten fsck, a maintainable dependency generator, 
integrating that nifty rpm upgrade...  Ok, it's not the world's shortest 
short list, but I'm grinding through it.)

Anyway, once you've got a UML binary called "linux", copy it into your 
busybox*/testsuite directory, cd busybox*/testsuite, and go:
  ln -s ../busybox mount
  ln -s ../busybox umount
  ln -s ../busybox losetup
  PATH=.:$PATH ./umlwrapper.sh mount

I just noticed it still gives you a command shell at the end of the test (in 
the UML + chroot environment), in case you want to run more tests by hand.  I 
need to clean that up, but oh well...

There are still various strange hiccups I can make it do, but nothing major 
just now, and considering I found two kernel bugs during testing (one a 
reproducible panic in 2.6.16-rc5, don't get too excited it requires root 
access to trigger) during testing I'd say I was reasonably thorough.  The 
current mount command is _way_ better than the previous version (assuming I 
haven't missed something dumb).

That means the ONLY blocking issue left is teaching passwd to use salt.  
(Which means I should dig up Tito's passwd.c and obscure.c rewrites and 
review them tomorrow.)  I should also troll the bug generator for low-hanging 
fruit.  Most of what I saw in there last glance was portability stuff, which 
can go in a future release.

So we're on course for a release Monday, but Erik said he wanted to push that 
back to Tuesday for a couple reasons.  He's got some patches in his inbox he 
wants to review this weekend, and there's a conference call late Monday 
afternoon that may affect the release announcement.  Tuesday it is, then.

This means I should actually start writing up a "what's new since 1.00" 
document.  Lotsa patches to review.

Bang on tonight's snapshot _hard_, guys.  And through the weekend.

Rob

P.S.  Yes, I'm aware that the sed null fix has been resubmitted several times 
after I said that I plan to do a major rewrite to fix it properly.  I've 
already reviewed at least five different versions of submitted fixes for this 
issue, all of which had something wrong with them, so reviewing more of the 
same is low priority at this point.  I also said I came to the conclusion I 
needed an intrusive change to the underlying assumptions (with embedded nul 
chars, strlen(data) is not the same as length of data) to actually correct 
the underlying problem, and although that's the correct fix it's too big to 
go into 1.1.1 this late.

Just reviewing and testing a correct fix for something that fundamental, 
widespread, and intrusive in a big applet like sed would be a lot of work.  
It's changing how the length of strings is determined throughout an applet 
that does complex string processing.  That affects everything.  No, the 
current sed testsuite is not close to complete yet.  And that's assuming a 
submitted fix was at least close to correct, which implies it's what I think 
needs to be done, rather than yet another attempt to fix it without such a 
rewrite, of which I've already looked at several versions and had to do work 
to find and explain where they would fail.

This is why I said it was not going to be fixed in 1.1.1 and I'd revisit the 
issue after the release.  I'm happy to fix this one (properly) myself, but 
after the time spent on it so far I'm not holding up 1.1.1 to even _review_ 
another fix at this point.

Sorry I didn't respond earlier on that, I was focusing on mount.  I feel 
everybody is owed at least an explanation of why their patch gets deferred or 
rejected, rather than just silence.
-- 
Never bet against the cheap plastic solution.
-------------- next part --------------
CONFIG_BINFMT_ELF=y
CONFIG_HOSTFS=y
CONFIG_SWAP=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_FUTEX=y
CONFIG_SHMEM=y
CONFIG_LBD=y
CONFIG_BLK_DEV_UBD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_STDERR_CONSOLE=y
CONFIG_CON_CHAN="fd:0,fd:1"
CONFIG_UNIX98_PTYS=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_VFAT_FS=y
CONFIG_PROC_FS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y