Re: patch to mount(8) to support optional filesystem mounts

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Fri, 23 Jan 2004 13:15:34 -0800 (PST)
Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:

>     Well, the problem here is that 99.9% of the system installations
>     do not need that sort of sophistication, and do need all the
>     mounts in/etc/fstab that aren't 'noauto' to be mounted for the
>     system and third party software to come up properly.  We do not
>     want support for more sophisticated situations to make life
>     difficult for 99.9% of the system operators out there that do not
>     need such support.
> 
>     So what this means is that extending fstab options should maintain
>     backwards compatibility, especially in this case where it just
>     isn't that big a deal to add an option for specially-handled
>     mounts that an rc file can then process.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>

Absolutely.

I'm pretty confident now that this can be seamlessly wedged into
something like /etc/rc.d/mountoptional, without disturbing the other
/etc/rc.d/mount* scripts (and especially without disturbing "mount -a".)

The optional mounts should be specified in /etc/fstab, with "noauto",
and /etc/rc.d/mountoptional should determine how/whether to mount them.
The clever bit then becomes having a nice way to tell mountoptional what
kind of rules to apply (defaulting, of course, to none.)

But my rcng-fu is not very strong, so I've been spending this time
trying to better comprehend rcng.  I have two questions, if someone is
willing to field them:

On or about the 17th, NetBSD and FreeBSD broke off mutual rcng
synchronization.  Does DragonFly plan to stay synchronized?  If not,
should the scripts be simplified to be OS specific, as NetBSD and
FreeBSD have done - is this a good/bad idea?

Also, there still seem to be a lot of places where the following sort of
idiom is used:

	case $variable in
		[Yy][Ee][Ss])
			...
		;;
		*)
			...
		;;
	esac

Should these eventually migrate to using checkyesno?  Some but not all
of them rely on the variable being either (e.g.) a program name, or
"NO".  Perhaps a related function, just 'checkno' or something, could be
used to clean up those sort of checks?

-Chris