>
>   | i understand. for same acl definition one file could be shared (both in
>   | disk and in memory)?
>
> That's the idea yes.   The "in memory" is "in the buffer cache" (ie: UBC)
> of course, just like directory data, etc - comes and goes as needed.
yes.
>   | so maybe only extra machine word be sufficient per inode.
>
> Could be that way, but to be more general, an associated type would be
> useful, so two extra words.   Big surprise that the on disk inode format
> has 2 spare words in it...  (There is a method to allow more than just
> one associated file as well, a little crude, but functional).  Because there
> are no incompatible changes to the on disk format, the worst that using
> an ACL filesys on a non ACL kernel can do (ignoring the fact that ACLs would
> not be honoured of course) is lose the ACL from files that are written
> (when the in-core inode is updated on disk).  (Here, "ACL" == "associated
> file" in the general case).
>
>   | containing 0 if no acl is used, and "acl" inode number if it is
>   | (which can be same for many file inodes).
>
> Exactly.
>
>   | acl inode can have the same data like normal file or
>   | dir, but pointing to acl definition data instead of regular file data.
>
> Yes, where the ACL file could be anything from a regular text file that
> you edit with vi (or whatever) and the kernel parses as needed, to a
> highly structured binary file, that can be altered only by root owned
> processes, and which the kernel can then rely upon the format of.  I don't
> care, ACL's were never a high priority for me, the general file system
> extension is much more interesting.
yes.
>   | this should make almost no slowdown if there is no acl used even with acl
>   | compiled in,
>
> That's my guess.  I'd think the slowdown would be smaller than for quotas,
> as there's nothing to write, all this is read only in normal operation.
> The "does not apply to this file" test should also be cheaper.
>   | while config option could be made to not compile acl support at all.
>
> Certainly.  And associated file support as well (that being necessary for
> ACLs if they get implemented this way, but useful for other things as well).
>
> kre
>