cvs commit: src/sys/ufs/ffs ffs_vfsops.c

[Robert Watson]

On Sat, 22 Apr 2006, Tom Rhodes wrote:

> Which is why I suggested that, similar to Linux, we make everything an 
> option instead of either Warning before you build/install the new kernel or 
> add the addition headache of turning it on later. Thus, I'm still of the 
> opinion that one does not blindly add a newfs option during the install 
> without understanding what's going on.

The problem you're diagnosing is booting a kernel that doesn't support 
features requested by the administrator.  When this happens, there are really 
only two things you can do:

(1) Generate warnings and continue.
(2) Generate warnings and stop.

We opt for (1) because it makes recovery easier.  Deleting the warnings helps 
neither case.  Booting an SELinux system without an SELinux kernel will fail 
in many spectacular ways, but I'm not sure if they generate a warning 
equivilent to the one you deleted.

BTW, turning on the multilabel flag in sysinstall is not an option offered by 
the installer -- by setting it using sysinstall's "additional flags" field, 
you're specifially doing something not part of the install path.  The MAC 
instructions I've provided always involve completing the normal install, 
building MAC support, etc, not turning it on in sysinstall and expecting it to 
work.  The only instructions I've distributed that involve setting multilabel 
in sysinstall relate to the SEBSD install ISOs, which explicitly support 
flagging multilabel support during the install.

>>> I'll revert it if you feel strongly about it; however, I want it
>>> to be known what my opinion is.  And I find the warnings
>>> extremely annoying and have answered at least one question as
>>> to why "mount don't show me correct output."  Yes, real quote.  :)
>>
>> mount != tunefs.  tunefs will tell you what options are enabled in the
>
> Yes.
>
>> filesystem, but I think mount should only tell you the options that are
>> actually in force.
>
> Once they're enabled does that not mean they are in force?

I'm not sure what you mean by "enabled" here.  Flags only have an effect if 
the kernel code to support them is compiled in.  The way the code was before 
you modified it, the flags could not be shown in mount if the kernel didn't 
implement them -- i.e., if you type in "mount" and don't see ACLs, then they 
are not implemented, and if you do see ACLs, then they are implemented.  With 
your change, they can now be set but not implemented.  I.e., you can look at 
mount, see "acls" set, but ACLs won't actually be in force, which I consider a 
more confusing failure mode.  If you mean, can they be enabled in tunefs but 
not in force -- yes, if you are running a kernel that can't support them.  In 
which case, before your change, a warning was generated, but not now.

Robert N M Watson