After two weeks of work, the NFS exports lists rototill that I briefly outlined in this past post is finished and committed into NetBSD's source tree. Believe it or not, the whole set of changes was triggered by a XXX mark in mountd(8)'s code (in other words, fixing code marked as such is not always trivial).
In the past, when a file system wanted to support NFS, it had to include two fields in a fixed position of its mount arguments structure due to the broken way in which mountd(8) handled the mount(2) calls. Furthermore, each file system had to deal internally with the NFS exports list, duplicating code among all NFS-aware file systems; this feature was clearly generic, so it had to be placed in an upper generalization level. At last, you had to use the mount(2) system call in a wired way to change the exports.
This was wrong because it broke extensibility and code cleanliness: you couldn't add a new NFS-aware file system without modifying and rebuilding mountd(8). There was also a lot of code duplication and the interface was just ugly from a design point of view. It looked like a quick band-aid over old code to add support for more than one NFS-aware file system.
The changes I just committed have centralized all NFS exports lists handling in a single place and it has been removed from the kernel's core. This stuff is now only compiled in when the NFSSERVER option is enabled, reducing the final kernel size by around 5KB.
The next logical step is to rework mountd(8) to update the whole exports list for a given mount point atomically; this wasn't possible at all before. The new kernel interface, introduced as a new command to the nfssvc(2), has been designed to support this functionality, although it's not used yet due to the big changes required in the userland utility. I won't be working on this anytime soon, as I have other stuff to do before it (hence the entry I added to src/TODO).
If you want to know a bit more, the commit message contains a detailed list of all the changes.
PS: I have to thank Google's Summer of Code 2005 again. I couldn't have found this issue nor had enough knowledge to fix it if I hadn't been working on tmpfs during the summer.
