On Sat, 10 Mar 2001, Greywolf wrote:

> # On Fri, 9 Mar 2001, Robert Elz wrote:
> # > I am going to ignore all the noise from the past day on this issue,
> # > and concentrate only on the technical issues.
> #
> # um, that 'noise' was the sound of opinions that differ (evidently) from
> # your own.
> 
> This "noise", actually, if you want to be constructive about it, is called
> "discussion", which is what we're all about.

Well, the "noise" didn't seem a terribly constrictive discussion. Many of
the negative points came across as, "It's not the *BSD way." That's
whapping with the religeon stick, which I've never found to lead to
constructive discussions (and I grew up in the "South" in the USA, where
bible thumping is high sport). And yes, one of the pro-ACL supporters got
as fervent on the opposite side.

> To summarise, I agree that ACLs would be useful to some degree, and I have
> a suggestion:  Does anything exist that still uses inode #1?  Do we *still*
> have bad sector forwarding that does that?  We could put the ACL information
> there.  Of course, fsck seems to want to link anything it finds with links
> and size, but no name, into lost+found...

We still run on hardware which doesn't support automatic bad sector
forwarding (while _I_ don't, older ports do :-) . So we should keep it.

> Summary of "The BSD Way":  On one side, we have the people who believe that
> progress is essential.  On the other side, we have the people who believe
> that progress is fatal.
> 
> At the risk of sounding paradoxical, you're both right, and you're both
> generating quite a discussion.  The problem is that neither side wants to
> listen to the other, and that's quite a schism to have created and for
> which to have taken responsibility.

The one thing I'd add to this is that we really shouldn't be whapping "the
BSD way" around. Certainly not to stop progress (which is what "the BSD
way" seems to be to me). That's not to say that folks can't disagree with
directions things are going and say so. Just keep the religion low. :-)

> After all this noise is said and done, it is going to boil down to:
> 
> 	Can this be done correctly as it stands?

We really need to see an implimentation before we can answer this. :-)

> 	If so, which fs layer(s) are we going to need to modify?  Since
> 	we're doing vfs->(every_other_fs), some vfs hooks will need to
> 	be put in, possibly returning EINVAL if ACL is not compiled
> 	into the kernel, for example.  We'll probably need hooks into
> 	ffs/ufs and nfs, as well; likely others.

No, we won't. We already have VOP_ACCESS(), which determines if you have
read, write, or exec privileges. To add ACL support, all we need to do is
add the extra flags whatever ACL method we use adds. All the extra flags
I've seen (the ones on AFS) are mappable to one of the three original
modes, so filesystems which don't do ACLs can easily be extended to deal
with the new VOP_ACCESS() flags (for instance, read and list access would
map to VREAD on an old-style filesystem). So we don't need a new VOP, and
it's not hard to change the MI (well fs-independent) parts of the kernel
to take advantage of ACLs. :-)

> 	If not, how much will fsck, newfs, dump and restore
> 	need to be modified to make this work, and how badly would
> 	this mangle the existing filesystem format?  Would it be to
> 	the extent that we'd need to invent a new filesystem to replace
> 	ffs?

Answering this question for the ffs tools will have to wait until we have
an implimentation to talk about.

I doubt we will need to impliment a new ffs. We may come up with a file
system which has a different magic number (thought bumping the superblock
and inode numbers is more likely), but I suspect it will be 95% to 99%
ffs. I also have some experience with this - while at NAS, I worked on a
large-inode ffs for one of the projects we were doing. When we went to
merge it in, we got shot down, so we did something else. But the changes
weren't that bad, and were just an option in the ffs code. If you didn't
want large inode support, you didn't add the option. :-)

Take care,

Bill