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

[Rob Landley]

On Tuesday 10 January 2006 15:45, Bernhard Fischer wrote:

> >> 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.

Hmmm...  Rummage, rummage...  Oh darn it, I remember this now.  Funky kernel 
behavior.  Great.

in the kernel's init/do_mounts.c, there's mount_root(void) with:
  create_dev("/dev/root", ROOT_DEV, root_device_name);
  mount_block_root("/dev/root", root_mountflags);

Suckage.  Ok, what's the least evil way to deal with this.  Hmmm...

In general, if the block device of a mounted filesystem points to a 
nonexistent file, we could do a lookup to see what it _should_ be called.  
But this is slow, and purely cosmetic since the info we want we get from the 
mount path, not the block device node.

Now if we do want the cosmetic lookup then in theory, the easiest way to deal 
with this is to grovel through /sys and try to find a matching entry in 
there.  (Rather than the groveling through /dev we're doing now, which is 
even slower.)  And possibly we could share code with mdev that does that, I'd 
have to fiddle.

But not day.  For now, I think just not doing the lookup at all, and feeding 
back whatever /proc/mounts gives us for the mount point's block device is 
probably the best way to go.  Clean it up properly in 1.2...

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.