Subject: RE: NFS exports
To: None <>
From: Gordon Waidhofer <>
List: tech-kern
Date: 05/25/2004 12:20:12
Exporting is handled by mountd(8) using mount(2).

Mount(8) and fsck(8) invoked external programs,
mount_fsfoo and fsck_fsfoo, and so are extensible without
modification. Mountd(8) is much more "brittle".

The export list is contained in the file system specific
mount paramters. This is, IMO, woeful overloading of mount(2).
Adding a new file system type to the system means mountd.c has
to be changed. The file system specific mount parameter
must be exposed to mountd.c through a header (.h) file.
Suppose 108 file system types are available and you want
47 of them. How are you going to come up with mountd?
Common mountd.c source is out of the question because you'll
be missing headers for 51 file system types. And that
would be the easy case.

The export list should be passed to the kernel using
a different interface than mount(2). This would make
the interface file system generic. Further, a general
fsctl(), kinda like ioctl(), would be handy for a lot
of things.

For my work... On NetBSD, I modified mountd.c for exports.
The other things for which I need an fsctl() kind of interface
are (temporarily) handled by woeful overloading of the
quotactl() interface. Long term, it would make sense to
have the quotactl() functionality folded into a more general


> -----Original Message-----
> From: []On
> Behalf Of
> Sent: Tuesday, May 25, 2004 10:58 AM
> To:
> Subject: re: NFS exports
> > Can I mark my filesystem as not NFS exportable (by design) and not
> > implement that funcationality?
> If NetBSD is like the other BSDen, exporting is done by mountd.c and
> it has to know about the file system type to do it. (In other words,
> it won't export by default.)
> rick
> ps: You could take a look at mountd.c and see what it does.