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 pr
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
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 Hu
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
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 d
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 i
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 porti
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.
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,
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 for
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 :
>
> (
Hello everyone,
Time for glibc questions :)
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
12 matches
Mail list logo
