Re: Question with moving mount/umount logic in glibc
Hello Samuel, can you send me a freelink? Thank you, Manolis On 04/03/2017 11:49 AM, Samuel Thibault wrote: > Hello, > > FWIW, Linux is considering to introduce another API to replace > mount(), that will be more fd-ish, and actually more hurdish, see > https://lwn.net/Articles/718638/ (I can provide a freelink to people > interested, the article will be available within one week anyway). > > Samuel >
Re: Question with moving mount/umount logic in glibc
Hello, FWIW, Linux is considering to introduce another API to replace mount(), that will be more fd-ish, and actually more hurdish, see https://lwn.net/Articles/718638/ (I can provide a freelink to people interested, the article will be available within one week anyway). Samuel
Re: Question with moving mount/umount logic in glibc
Roland McGrath, le Thu 06 Aug 2015 01:01:55 -0700, a écrit : > then a header that defines away the functions as > no-op always-fail or no-op pretend-to-succeed or something else distinct > from "implement as a faithful emulation of Linux usage regardless of the > sensibility of such usage on the Hurd" could well be the most useful thing. Or maybe not: providing such a failing call makes those programs enable portions of code it expects to succeed, and thus getting new failures. It would indeed probably be useful to actually check these usage before including mount(). Samuel
Re: Question with moving mount/umount logic in glibc
The grepping doesn't tell us whether those programs are using the interface in a way that's actually useful (either at all or specifically in the Hurd context). If the motivation is just to get more sloppily-written programs to compile out of the box, then a header that defines away the functions as no-op always-fail or no-op pretend-to-succeed or something else distinct from "implement as a faithful emulation of Linux usage regardless of the sensibility of such usage on the Hurd" could well be the most useful thing.
Re: Question with moving mount/umount logic in glibc
Hello, Olaf Buddenhagen, le Wed 05 Aug 2015 19:53:11 +0200, a écrit : > Having said that, *if* it's actually common practice nowadays to > (mis)use the mount(2) call directly, I'd say it *might* indeed be more > convenient to implement a compatibility wrapper at the libc level... 14 packages in debian at least currently require it: € wanna-build --list=failed | grep sys/mount.h | wc -l 14 And codesearch shows many more results, like a few hundreds: http://codesearch.debian.net/results/sys%2Fmount%5C.h/page_0 Samuel
Re: Question with moving mount/umount logic in glibc
Hi, On Fri, Jul 10, 2015 at 12:37:04AM +0200, Ludovic Courtès wrote: > Roland McGrath skribis: > > Frankly I think it would be better to keep these single-caller > > interfaces out of libc proper. It's not really ideal that they are > > there for Linux either, but syscall stubs are less of an issue than > > real code. > > While not ideal, I think it would greatly simplify porting to have > libc provide those functions regardless of the kernel. I think what Roland is trying to say here is that the mount(2) call is not really intended as an API, but rather just a system-specific low-level syscall wrapper existing solely for the convenience of the system-specific mount(1) utility implementation; and other programs have no business invoking it directly at all. (At least that's my impression...) Also, the semantics of translators have some subtle differences from "traditional" mount points -- so I'm not sure it's really a good idea to let applications believe they are dealing with the same mechanism... Having said that, *if* it's actually common practice nowadays to (mis)use the mount(2) call directly, I'd say it *might* indeed be more convenient to implement a compatibility wrapper at the libc level... -antrik-
Re: Question with moving mount/umount logic in glibc
Roland McGrath skribis: > Frankly I think it would be better to keep these single-caller interfaces > out of libc proper. It's not really ideal that they are there for Linux > either, but syscall stubs are less of an issue than real code. While not ideal, I think it would greatly simplify porting to have libc provide those functions regardless of the kernel. Ludo’.
Re: Question with moving mount/umount logic in glibc
Frankly I think it would be better to keep these single-caller interfaces out of libc proper. It's not really ideal that they are there for Linux either, but syscall stubs are less of an issue than real code.
Re: Question with moving mount/umount logic in glibc
Quoting Ludovic Courtès (2015-07-07 22:29:05) > Justus Winter <4win...@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
Re: Question with moving mount/umount logic in glibc
Justus Winter <4win...@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.) Ludo’.
Re: Question with moving mount/umount logic in glibc
Hi Manolis :)
Quoting Manolis Ragkousis (2015-07-07 16:04:30)
> I have a question about utils/mount.c. In the contribution page it says
> "Move the mount/umount logic from utils/{,u}mount.c into glibc".
>
> After a short conversation with Thomas here 's how I think I will implement
> it :
>
> (glibc)/sysdeps/mach/hurd/mount.h : Declarations of mount, umount,
> umount2 and possible
> flags as described in
> http://www.gnu.org/software/libc/manual/html_node/Mount_002dUnmount_002dRemount.html
> and compared to [glibc]/sysdeps/unix/sysv/linux/sys/mount.h, so we can
> stay compatibile at the API level
> with other systems.
Yes. Compatibility is Hurds killer feature.
> WDYT? Please feel free to comment/suggest. :-)
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.
Cheers,
Justus
