On Thu, Dec 12, 2013 at 09:53:25PM +0000, Al Viro wrote:
> Frankly, I wonder if we are trying to pack too much into one
> syscall - not just in terms of overloading it (that much is obvious),
> but in terms of trying to cram a sequence of syscalls into one. If
> we end up introducing new API(s) for mount(), it's probably worth
> considering something like this:
> * open a connection to fs type driver, get a descriptor
> * use normal IO syscalls (usually just write(2)) on that
> descriptor to tell fs type driver what do we want. If any kind of
> authentication is needed, that's the time for doing it
> * attach the thing identified by that descriptor to mountpoint
Yes, exactly. This is my wish for years.
I don't think we need more *independent* syscalls to replace mount(2)
(for example a special syscall to change propagation flags, or so).
I strongly believe that APIs for complex tasks have to be based on
handlers (file descriptors). These APIs are extendible.
It would be also nice to provide some information about the mount
operation to userspace by the file descriptor -- it means to support
read(2) and at least to return mount Id. The current situation when
we have only errno in userspace is insufficient. If you want to know
more information then you have parse /proc/self/mountinfo, but which
entry in the right entry for the last mount(2) call?
> I have an old writeup somewhere (several variants of it, actually) on possible
> replacement APIs; I'll try to dig it out and post it.
Please, share it :-)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
