bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question with moving mount/umount logic in glibc


From: Justus Winter
Subject: Re: Question with moving mount/umount logic in glibc
Date: Wed, 08 Jul 2015 10:21:02 +0200
User-agent: alot/0.3.5

Quoting Ludovic Courtès (2015-07-07 22:29:05)
> Justus Winter <4winter@informatik.uni-hamburg.de> skribis:
> 
> > Sounds awesome.  One thing to be aware of (iirc) is that the
> > mount/umount code depends on the fstab parser.  I'm not sure whether
> > it is needed for the mount/umount(2) interface, or just for the
> > command line frontend.  I bet the former, that means that you also
> > have to move the fstab parser to the libc.
> 
> /etc/fstab handling is not part of the mount/umount functions (on Linux
> mount and umount are syscall wrappers generated from syscalls.list.)

That's right, but /bin/umount can be called with both the device path
and the mount point.  In utils/umount.c this is done by parsing
/proc/mounts using the fstab parser.  I just checked umount(2) and it
says:

> The original umount() function was called as umount(device) and
> would return ENOTBLK when called with something other than a block
> device.  In Linux 0.98p4, a call umount(dir) was added, in order to
> support anonymous devices.  In Linux 2.3.99-pre7, the call
> umount(device) was removed, leaving only umount(dir) (since now
> devices can be mounted in more than one place, so specifying the
> device does not suffice).

So indeed, we don't need the fstab parser to emulate current Linux
behavior.

Justus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]