Ok guys, test svn 13222. It's 1.1.0-rc1.

[Bernhard Fischer]

On Tue, Jan 10, 2006 at 02:01:15PM -0600, Rob Landley wrote:
>On Tuesday 10 January 2006 05:31, Bernhard Fischer wrote:
>> Did you forget to bump the version to -rc1 in Rules.mak or is Erik
>> supposed to do that when he creates the tarball? Just curious..
>
>I forgot.  It had been a long day. :)
>
>Bumped.

Thanks :)
>
>> Tito did start to look at passwd.. Tito, willing to take a look at md5
>> there? IIRC it should/could use the passwd stuff from libbb/ instead of
>> crafting it's own copy. As a nice side-effect of fixing #604, it would
>> potentially shrink it :)
>
>Documenting it might be nice too.
>
>I've started work on a "programming.html" file for the website.  I'll post it 
>in a few days, once I get it filled out more.  It's sort of a code-side FAQ.
>
>The index so far (obviously a work in-progress) is:

Sounds promising. I'm looking forward to it.

>> >0000403     Networking Support  minor  ifup -a" seems to ignore
>> >up/down/pre-up/pre-down in /etc/network/interfaces
>> >
>> >I use ifconfig rather than ifup, and although I've been known to learn a
>> > new tool to fix a bug, I'm not holding up the release for it either.
>>
>> Do you also have 'run-parts /etc/network/if-%s.d' (for execute_all) or
>> just the 'up' etc. keywords in interfaces?
>
>Again, I don't use this stuff.  The systems I put together have very simple 
>("bsd-style") init scripts.  I thought run-parts was a debian utility.
>
>I'm all for fixing it, but this close to a release I'm not poking at the parts 
>where I don't personally know what "good and working" looks like.

If the initial reporter is listening, please answer, TIA.

>> >These are either optimizations, cosmetic fixes, or new feature requests.
>> >Fodder for 1.1.1...
>> >
>> >0000145     Standards Compliance  major  Fix strange behavior when issue
>> > df with pseudo root device(/dev/root).
>> >
>> >I'm still confused from reading the bug report.  The patch is pretty
>> >straightforward but I'm not quite sure what the issue is.  (If we
>> > shouldn't be looking up a real root device for /dev/root, then don't do
>> > that.  Don't compare and block the name to prevent us from doing a
>> > special case lookup...)
>>
>> I glanced at it a while back and think it should be fixed for the 1.1.0
>> release.. Not sure if i will find the time, unfortunately.
>>
>> The issue is this:
>> # cat /root/busybox.mtab
>> rootfs / rootfs rw 0 0
>> /dev/root / ext2 rw 0 0
>> # df -f /root/busybox.mtab
>> Filesystem           1k-blocks      Used Available Use% Mounted on
>> /dev/root               121459      3891    117568   4% /
>> # df -f /root/busybox.mtab /
>> Filesystem           1k-blocks      Used Available Use% Mounted on
>> #
>> i.e. the skipping logic works if walking the whole mounts file but fails
>> if searching the specific '/' path.
>
>I know our current behavior is kinda horked, I'm wondering if the correct 
>behavior is to rip out special case handling for /dev/root and tell people 
>"ok, either /dev/root is a symlink pointing to your real root device, or it's 
>a mknod of a device that does the redirection for us, or you _don't_use_it_."

Perhaps i misnomed the file a bit, these lines are actually from
/proc/self/mounts.

I should most likely (re-)read the whole mounts file if a match for
"rootfs" was found for the specific mount point i was asked about..
>
>This pretty much seems to be an mtab problem.  /proc/mounts doesn't get 
>confused about what the last mount on / is.  (The paths can change out from 
>under it after chroot or pivot_root, of course.)  But the "skip rootfs" logic 
>also goes away if we just collate the mounts and skip any mounts that are 
>completely hidden by later mounts.  (Or duplicates.)
>
>I'm growing less and less interested in humoring mtab as time goes on, because 
>the kernel's moving away from it.  (Name spaces are just the tip of the 
>iceberg.)  If our code's going to be bigger I want to know what the benefit 
>is, and the benefit of supporting this /dev/root groveling (which is also 
>_slow_) is something I'm still a bit fuzzy on...
>
>(And on an implementation note, df does statfs on the mount point anyway, not 
>on the device.  The device is cosmetic, so why is trusting what /proc/mounts 
>tells us a bad thing here?)
>
>I'm often confused or underinformed (or just plain wrong) about these sort of 
>things, I'm happy to listen to a coherent explanation of this if somebody's 
>got it...