Re: Named streams, Re: Cleaning up namei

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Mar 23, 2008 at 02:23:07PM -0700, Bill Stouder-Studenmund wrote:
 > > > Mac OS used to have "complex" vnodes, which were files that had named 
 > > > forks. They acted like files, but you could do lookups on them. Mac OS
 > > > no longer has them, so I consider them a dead experiment. ;-)
 > > 
 > > But there's no reason they should be prohibited by the VFS layer.
 > 
 > I believe there is. It adds complexity, and I feel we win nothing for the 
 > complexity. Look at all the issues you are having with the complexity we 
 > actually use!

That's quite true, except that the conclusion I drew upthread was that
the vfs layer doesn't have to do anything special; it's up to the fs
to decide to offer VOP_LOOKUP (and/or CREATE, LINK, RENAME, etc.) on
regular files as well as directories. I don't think any particular
complexity results; *forbidding* that somehow would add complexity.

 > No one really needs to be able to handle named streams this way, so let's 
 > not.

Granted. Also, I tend to think multistreamed files are an abomination;
I'm not about to go rush out and implement them. There are dozens of
perfectly good container formats one can use... native multistreamed
files serve next to no purpose and make life difficult for users and
sysadmins.

I would, however, like to avoid coding in assumptions about what vnode
types can support what operations; that way the behavior is only
specified in one place instead of several. If we decide the latitude
of fses to do weird things should be restricted, the best way to do
that is some kind of compile-time check on VOP lists.

-- 
David A. Holland
dholland%netbsd.org@localhost