--dkEUBIird37B8yKS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 15, 2006 at 08:38:22PM +0200, Elad Efrat wrote:
> Bill Studenmund wrote:
>=20
> > Then don't do it. As in don't check it in.
> >=20
> > My understanding of metahook was that it was to abstract out what was=
=20
> > needed for Veriexec, and to make it so that it and other services can=
=20
> > operate w/o having each one of them need to shove something different i=
nto=20
> > all the VFS-layer routines.
>=20
> 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=20
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=20
systems. I see no reason your infrastructure is meaningless, other than=20
that you are making it so. :-(

Also, to me, Veriexec makes sense on a networked file system. It can be=20
VERY USEFULL on a networked file system. You are abstracting what Veriexec=
=20
does, thus it seems logical for Veriexec to use what you do. Thus Veriexec=
=20
will start using an infrastructure that won't work with networked file=20
system. That seems bad.

Or are you proposing abstracting out some of Veriexec's data handling yet=
=20
not have veriexec use it?

> > What complications do you see in extending metahook(9) to support=20
> > networked file systems?
>=20
> 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=20
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.
>=20
> 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=
=20
your abstraction.

You also are using identifiers (dev_t and inode_t) that really shouldn't=20
be used outside of the file system. We have cleaned-up abstraction=20
structures (file handles, for example) that remove much of the problem=20
wiht what you're doing. Their existence predates my use of NetBSD, and=20
actually they predate NetBSD. Yet you aren't using them.

=46rom looking at the man page, I see no reason why metahook(9) won't work=
=20
with networked file systems. Other than your use of inode number. THAT'S=20
IT! I may be missing something, but you are VERY close to doing it right.=
=20
Like 10% away or so. Please, just make those small changes, and you will=20
give NetBSD an API that can be very helpful.

Plus, generation numbers are important, even for local disk stores. Since=
=20
you aren't storing pointers to the vnodes, use file handles.

Take care,

Bill

--dkEUBIird37B8yKS
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEkaIUWz+3JHUci9cRAhg0AKCNzw809EMzNxNzpE+weYOoQsvPYQCdGqCz
IYu8KesBgYMmYxCcHq88z5k=
=CDJh
-----END PGP SIGNATURE-----

--dkEUBIird37B8yKS--