[BusyBox] Re: [BusyBox-cvs] svn commit: trunk/busybox: include networking

[Rob Landley]

On Friday 29 July 2005 06:47, Ladislav Michl wrote:
> On Thu, Jul 28, 2005 at 02:27:10PM -0500, Rob Landley wrote:
> > Again, how did the behavior you got differ from what you expected?  Mount
> > operates on device files, not on magic names.  If you specify a relative
> > path and a program turns that into an absolute path by taking the current
> > working directory into account (correctly removing ./ and ../ and // and
> > so on) then where's the harm?  How does passing a relative path or an
> > absolute path to the same file differ in behavior?  (Are you saying we're
> > turning it into the WRONG absolute path?)
>
> First, mount _does_ operate also on "magic" names. You can easily mount
> usbfs, tmpfs, sysfs, proc, etc.

Those are filesystem types in -t, and it gets the names out of 
either /etc/filesystems or /proc/filesystems.  (I'm told heuristics to 
autodetect file types have been added recently, but that's a seperate issue.)

These are not magic directory names.  Associations between directories and 
block devices are done in /etc/fstab, not hardwired into mount.  And 
again, /etc/fstab is not going to have a relative path in it.

> Now, MTD are not block devices (but there 
> is block caching layer) and jffs2 operates directly on MTD. Historicaly,
> block MTD was only needed to get mount point. Now it is also possible to
> specify MTD name, so you do not need to have block device emulation
> enabled. You can mount such devices this way:
> mount -t jffs2 /dev/mtdblock1 /mnt        [1]
> mount -t jffs2 mtd1 /mnt                  [2]
> mount -t jffs2 mtd:somename /mnt          [3]
> (last example assumes mtd1 is named "somename"). There are following
> problems with mount:
> * when /dev is working directory mtd1 (in [2]) gets expanded to
>   /dev/mtd1 which is _wrong_. Solution is either patch I sent earlier or
>   in case you want to 'normalize' device name, just check if it is block
>   device (see patch below)

So basically, you're requesting a new feature.  There are several possible 
things you can mount filesystems on.  We currently support block devices by 
default, and have config options to add support for loop devices and for NFS.  
We don't support Samba, and apparently we don't support whatever this MTD 
thing needs either at the moment.

> * when support for NFS is enabled [3] will fail, because test for NFS
>   share is done by searching ':' in device name.

Yeah, and that's a bit of a hack.  I haven't addressed it in the rewrite 
because I don't use NFS and thus wouldn't notice if I broke it, so I left 
that part mostly as it was.

Rob