Bill Studenmund <wrstuden@nas.nasa.gov> writes:
> I'll try to get the diffs on cvs.netbsd.org today. And I won't committ
> anything until developpers have had a chance to look at them. :-)

as far as i'm concerned it's absolutely unreasonable to commit them
until you've provided a design document that states what you did, why
you did it, what problems that you solved, and what problems exist in
your implementation.

to be honest, providing the diffs does little.  it tells what you
implemented, not why, or what implications it has.  when modifying
something so critical as the file system, in a way that has
implications as far reaching as the ones you've described, much more
than that is necessary.

I mean, hell, what you're proposing here is, among other things:

	* adding a bunch of 'opaque data' with no statement of who
	  owns that opaque data -- or even how you'd determine who
	  owns it -- and without much information about how it is
	  or should be manipulated.

	* adding a system call that's the moral, if not literal,
	  equivalent of ioctl() -- a call that many would say is
	  a mistake to begin with -- when it's not even obvious that
	  you need or want wuch a call to begin with.  8-)


I think the whole notion of larger inodes, with a bunch of 'reserved
space' for now (until the meaning of that reserved space -- even use
as 'opaque data' -- is resolved) is reasonable.  That i wouldn't mind
for e.g. 1.4.  I.e. _just_ the technical details of resizing the
inodes.

There just isn't time in the week or week and a half before the 1.4
cut to do the rest of the necessary thinking about the design, as far
as i'm concerned.  Not to say that your intuition or design is somehow
lacking, but the community needs to stare at it and think about it for
a while before committing to a major system interface change.


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.