[omnibus response here, to about five messages]

[responding to isildur's response to me]

>> As for technical merits...I can't see any way an ACLified FFS
>> filesystem could possibly interoperate with a completely
>> non-ACLified FFS kernel; almost by definition, the non-ACLified
>> kernel won't know about however it is that the ACLs are stored and
>> hence won't, for example, be able to free it when an object with
>> ACLs is destroyed.  You'll have to either bloat the mainline or lose
>> interoperability.

> Actually, there are ways.  It should not be too difficult to find a
> bit somewhere to specify that a given file has an ACL.

Yes.

> A non-ACLified FFS can ignore it.

Yes...but.

> An ACLified one can then worry about where to find and store the ACL
> in a nonconflicting manner.

But where?  There just isn't any significant amount of slack storage
space available to store the ACLs.  If you allocate data blocks for
them, they will be swept up as "allocated but unreferenced" by a
non-ACL-aware fsck...or, if you don't mark them as allocated in a way a
non-ACL-aware kernel will understand, overwritten by new allocations.
Every other place I can think of to store them imposes an unreasonably
small maximum on the amount of space a given file's ACL can occupy.
(There are only 64 spare bits in struct dinode, 160 bits if you steal
di_u, di_uid, and di_gid as well.  I saw someone mention directory
entries, but that runs into trouble with hard links, and also imposes a
limit somewhat under 256 bytes.)

I just can't see any way to make an ACLed filesystem work on a
non-ACL-aware machine, and given that, I don't see any reason to pay
any attention to FFS compatability except insofar as it allows you to
share code between ACLified FFS and non-ACLified FFS.

Now, one thing occurs to me.  I have already added code to FFS to make
it possible for the root point of the mount to be other than the
on-disk root of the filesystem (for example, if I have an alternative
root filesystem, I can mount its /usr/src on my /usr/src; everything
not under /usr/src in the mounted filesystem will simply be
inaccessible).  It might be possible to use on-disk structures
compatible with FFS by doing something like having /data and /acl (from
a non-ACL-aware POV) with /data being the file data and /acl holding
the ACLs, possibly in a parallel tree or possibly indexed by inumber or
some such.  A non-ACLified FFS would simply see data/ and acl/
directories, and would need compatability tools to make much sense of
the acl/ stuff; when mounted with ACLs, the filesystem ACL code would
unify it all.

If done right, this would have the advantage that it could be layered
on top of anything, not just FFS.  (Which is coming back to the "make
it a layered filesystem rather than hacking ffs" thread, which I think
is good both because it makes it easier to get rid of it for those who
don't want it and because it means that you can use it on ext2fs, nfs,
cd9660, etc, not just ffs.)

[wrstuden talking about the disk compatability issue]

> Also, think about what we're talking about.  Under what circumstances
> would an ACL'd ffs get handed to a non-ACL'd kernel?  Either 1) it's
> a file system that moves around a lot (like a floppy), or 2) the
> proverbial dung and fan have met.

True enough.  But it would be nice if moving a disk that has ACLs on it
to a non-ACL-aware machine could allow recovering the data, at least.
Either the overlay-fs way or the dual-tree way I alluded to above
(somewhat akin to the way quotas are stored in quota files) meets this
criterion.

[responding to thorpej's response to my response to...wrstuden, I think
it was?]

>> You are making an unstated assumption in this argument: you are
>> assuming that the ACLified filesystem must be an entirely in-kernel
>> filesystem.  I said - am saying - I don't think it should be.

> Well, there obviously needs to be some communication hook in the
> kernel.

Yes...but I'd much rather see it be something non-ACL-specific, like
portalfs, or even layered over the nfs support (a la Sun's tfs).

Or, if you really want it to be in-kernel, make it an overlay fs.

[and thorpej writing on the "keep NetBSD BSD" thread]

> That's not to say that we are going to throw away all vestiges of BSD
> (quite the contrary -- we're all here because we *like* the way BSD
> did things!),

I am here because I liked the way BSD did things.  But whatever it is
that I like about the BSD way (and I can't be more precise than that
because I don't know it any more precisely than that), NetBSD has been
steadily diverging from it.  (Why am I still here?  Two reasons: (1)
inertia and (2) lack of any real choice; NetBSD is the least bad of the
available alternatives for my hardware.  When I get some spare time, I
want to sit down and try for something fundamentally different.  I have
no idea whether anything good will come of it....)

[greywolf]

> Hard to say this, but if the feature makes sense AND we can do it in
> a non-performance-impactive manner

Yes...*if*.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B