1) Basic: The code to create the nfsiod kernel threads is fugly. As
the author mentions, if we use nfs as a module, insmod's memory is
kept around until the nfsiod's exit, and it keeps insmod's name. These
are mostly aesthetic issues, but still, it doesn't look too good for a
release kernel.
2) Slightly more of an issue: nfs will no longer unload automatically
when all nfs fs's are mounted, because the nfsiod's keep the module in
use even after the filesystem(s) are unmounted. An admin has to kill
the nfsiod processes to unload the module, which goes against the
spirit of kerneld, IMHO. Also, I question whether there should be 4
all the time, or whether it should be per-fs, or dynamic.
These first 2 issues might be handled by making mount schedule the
nfsiod's, and umount tell them to die? Set some sort of flag to tell
the kernel to start them up the next time it gets someplace? I'm not
really sure what's the mest way to do this..
3) Assuming the first paragraph, there's a race condition in the
nfsiod thread if 2 nfsiod's create their req's at the same time. #1
sets it's next to the head, #2 sets it's next to the head, one becomes
the head, the other becomes the head and we have an orphaned request,
which never gets used, disabling that nfsiod. I'm not sure how
probable/possible this is in practice, but it doesn't sound like a
good thing :)
Any feedback?
-Larry