On 6/15/06, Bill Studenmund <wrstuden@netbsd.org> wrote:
> On Thu, Jun 15, 2006 at 08:38:22PM +0200, Elad Efrat wrote:
> > Bill Studenmund wrote:
> >
> > > Then don't do it. As in don't check it in.
> > >
> > > My understanding of metahook was that it was to abstract out what was
> > > needed for Veriexec, and to make it so that it and other services can
> > > operate w/o having each one of them need to shove something different into
> > > all the VFS-layer routines.
> >
> > Actually, it was an abstraction to satisfy two very specific features I
> > planned on working on. These features simply are meaningless with
> > regards to networked file-systems.
>
> Why?
>
> My understanding of veriexec is that it makes sense on a networked file
> system, and to quote you:
>
> 'I have a working abstraction of Veriexec's meta-data code in a generic
> API to allow more than one "consumer" to associate private data with
> files. (device/inode pairs)'
>
> So what if your features are meaningless with regards to networked file
> systems. I see no reason your infrastructure is meaningless, other than
> that you are making it so. :-(
>
> Also, to me, Veriexec makes sense on a networked file system. It can be
> VERY USEFULL on a networked file system. You are abstracting what Veriexec
> does, thus it seems logical for Veriexec to use what you do. Thus Veriexec
> will start using an infrastructure that won't work with networked file
> system. That seems bad.
>
> Or are you proposing abstracting out some of Veriexec's data handling yet
> not have veriexec use it?
>
> > > What complications do you see in extending metahook(9) to support
> > > networked file systems?
> >
> > It's something that *I* don't have the time to look into doing. If
>
> I'm sorry, you missed my question. It was only partly, "why aren't you
> working on this." It was much more, "What are the issues with networked
> file systems." I don't see any, with the proposed interface.
>
> > someone else wants to look into it, fine. If nobody wants to look into
> > it and ther's a veto on introducing the interface without supporting
> > networked file-systems, also fine -- but keep in mind that this is
> > ridiculous in levels even new in NetBSD-land because (a) in the four
> > years Veriexec exists no other demand was for its meta-data association
> > code and (b) the features I was working on are meaningless for files
> > on networked file-systems.
> >
> > Basically, you are ruling out an interface that can have near immediate
> > benefit to NetBSD for reasons that don't exist. :)
>
> You are trying to make an abstraction, yet you are unnecessarily limiting
> your abstraction.
>
> You also are using identifiers (dev_t and inode_t) that really shouldn't
> be used outside of the file system. We have cleaned-up abstraction
> structures (file handles, for example) that remove much of the problem
> wiht what you're doing. Their existence predates my use of NetBSD, and
> actually they predate NetBSD. Yet you aren't using them.
>
> From looking at the man page, I see no reason why metahook(9) won't work
> with networked file systems. Other than your use of inode number. THAT'S
> IT! I may be missing something, but you are VERY close to doing it right.
> Like 10% away or so. Please, just make those small changes, and you will
> give NetBSD an API that can be very helpful.
>
> Plus, generation numbers are important, even for local disk stores. Since
> you aren't storing pointers to the vnodes, use file handles.


I also agree that veriexec over nfs would be very, very useful.  I
like veriexec for things like web content more than I do for libraries
and system stuff;  So working over nfs would be very nice.