> On Wed, 2008-02-27 at 21:17 -0800, Andrew Morton wrote:
> > On Tue, 26 Feb 2008 12:23:55 +0900 (WST) Ian Kent <raven@them...> wrote:
> > > Hi Andrew,
> > >
> > > Patch to add miscellaneous device to autofs4 module for
> > > ioctls.
> > Could you please document the new kernel interface which you're proposing?
> > In Docmentation/ or in the changelog?
> > We seem to be passing some string into a miscdevice ioctl and getting some
> > results back. Be aware that this won't be a terribly popular proposal, so
> > I'd suggest that you fully describe the problem which it's trying to solve,
> > and how it solves it, and why the various alternatives (sysfs, netlink,
> > mount options, etc) were judged unsuitable.
> It appears I could do this with the generic netlink subsystem.
> I'll have a go at it.
I've spent several weeks on this now and I'm having considerable
difficulty with the expire function.
First, I think using a raw netlink implementation defeats the point of
using this approach at all due to increased complexity. So I've used the
generic netlink facility and the libnl library for user space. While the
complexity on the kernel side is acceptable that isn't the case in user
space, the code for the library to issue mount point control commands has
more than doubled in size and is still not working for mount point
expiration. This has been made more difficult because libnl isn't
thread safe, but I have overcome this limitation for everything but
the expire function, I now can't determine whether the problem I have with
receiving multicast messages, possibly out of order, on individual
netlink sockets opened specifically for this purpose, is due to this or is
something I'm doing wrong.
The generic netlink implementation allows only one message to be in flight
at a time. But my expire selects an expire candidate (if possible), sends
a request to the daemon to do the umount, obtains the result status and
returns this as the result to the original expire request. Consequently, I
need to spawn a kernel thread to do this and return, then listen for the
matching multicast message containing the result. I don't particularly
like spawning a thread to do this because it opens the possibility of
orphaned threads which introduces other difficulties cleaning them up if
the user space application goes away or misbehaves. But I'm also having
problems catching the multicast messages. This works fine in normal
operation but fails badly when I have multiple concurrent expires
happening, such as when shutting down the daemon with several hundred
active mounts. I can't avoid the fact that netlink doesn't provide the
same functionality as the ioctl interface and clearly isn't meant to.
So, the question is, what are the criteria to use for deciding that a
netlink based implementation isn't appropriate because I think I'm well
past it now?