[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question with moving mount/umount logic in glibc
From: |
Olaf Buddenhagen |
Subject: |
Re: Question with moving mount/umount logic in glibc |
Date: |
Wed, 5 Aug 2015 19:53:11 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hi,
On Fri, Jul 10, 2015 at 12:37:04AM +0200, Ludovic Courtès wrote:
> Roland McGrath <roland@hack.frob.com> 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,
Olaf Buddenhagen <=