Teach mdmfs about tmpfs and use tmpfs in rc scripts

[Ian Lepore]

On Sat, 2014-03-08 at 22:24 +0800, Jia-Shiun Li wrote:
> On Fri, Mar 7, 2014 at 9:36 PM, Ian Lepore <ian at freebsd.org> wrote:
> > I'm not sure what you mean.  If the device on the command line is md the
> > program behaves as it always has.  If you ask for 'auto' you get the
> > "best" memory filesystem available for some definition of "best".  If
> > you don't trust someone else's definition of best (like you need failure
> > at allocation time) then you choose the one that behaves the way you
> > like.
> 
> ehh.. sorry read too fast and did not realize you 'added' new options
> in addition to existing 'md'. My bad.
> 
> I did not use mdmfs often. My understanding is that it is the help to simplify
> mdconfig-newfs-mount process to replace a one-step mount_mfs.
> Then I agree with Konstantin, it does not look too appealing.
> If the goal is to merge all memory-backed fs to single versatile command,
> then the proposal does the job. Otherwise one mount_tmpfs comamnd does
> all user needs for tmpfs, and I am not sure the auto decision is good if
> user did not know what he need or care. It seems better to leave the decision
> to user.
> 
> And for rc usage, I think we can just change it to tmpfs. If in the future tmpfs
> grows ability to populate content with e.g. a cpio archive at boot time or
> passed from command line, md usage can be further replaced.
> 
> -Jia-Shiun.

Okay, if people think that all this work should be done in the rc
scripts rather than in a program, then the rc scripts need to be changed
to do what I did in the program: honor existing options that make sense
for tmpfs (any -o options for the mount, translate -s to size=, and
don't use tmpfs if the config requests multilabel MAC).  And the changes
need to happen in rc.subr and in rc.initdiskless which doesn't use
rc.subr.  Oh, and of course, don't do any of it if tmpfs isn't
available.

If this isn't done, peoples' existing configurations may break (in the
case of the MAC option, break in a way with potential security
implications).

I've gotta say, I don't understand the basic resistance to having a
single unified tool for configuring a memory filesystem.

-- Ian