Terry Lambert writes:
> You're missing the fact that the file system support may have arrived
> as the rsult of a union mount, and that the organization to allow
> this requires that the per-FS components be logically and simply
> seperable from the other components.
> 
> For instance, I may wish to have a directory overlay from /usr for
> the additional fs's other than FFS, since only FFS is needed for boot.
> This is only an example of something I might want to do.

This makes no sense.

The names of your programs have NOTHING to do with union mounts. You
can name them anything that doesn't conflict and union mount
them. Not, of course, that this is a reasonable use of union mounts,
but if it was, your comment still would make no sense.

None of what you have said give any good reason why you might want to
name something ffs_mount or ffs/mount instead of mount_ffs.

> I can provide others, if necessary, and if you want to spend the
> time on them.

I'm still waiting for the first reason.

> In reality, given the discussion Doug Rabson, Mike Smith, and I had,
> it should be obious that an ELF executable could be considered a
> "bootfs" image, and all other FS types could result from a directed
> overlay from that into a real FS name space.  That is, i support
> variosu FS types as single modules which may be agregated with boot
> and kernel images.

Not that this makes any sense (because it doesn't) but that still says
nothing about why you might want to name something ffs_mount instead
of mount_ffs.

> All the better to boot from VFATSFS or EXT2FS as root and have a kernel
> that doesn't support FFS at all until a module is loaded from one
> of the FS types it does support.

None of this explains why you need to name the files "ffs_mount"
instead of "mount_ffs".

Perry