Date: Mon, 9 Mar 1998 03:44:12 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: tlambert@primenet.com, nate@mt.sri.com, dima@tejblum.dnttm.rssi.ru, current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system Message-ID: <199803090344.UAA17601@usr08.primenet.com> In-Reply-To: <199803090300.UAA13920@mt.sri.com> from "Nate Williams" at Mar 8, 98 08:00:47 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Terry wants FS implementors (therefore all FS's) to explicitly write
> > > code for vnode_pagers, rather than having the (potentially buggy) code
> > > used by FS writers.
> >
> > Terry wants local media FS implementors (therefore all non-stackable
> > FS's) to explicitly write code for vnode_pagers as payment for their
> > direct consumption of OS-specific kernel internals.
>
> Same thing, different way of putting it.
???
Can't you diff "all FS's" and "all non-stackable FS's"?
> Screw the design when it comes to having buggy/non-working FS's. That's
> one of the rules of getting your code committed. If your solution isn't
> complete, then it shouldn't be committed.
That's BS. I've tried that road before, and the code has been
consistently refused commit.
I've bowed to (IMO, unreasonable) pressure to get there incrementally, and
now you are bitching that the code's not getting there all at once.
It would be nice if you would make up your mind.
> So, if you didn't provide
> patches to *all* existing code then you should be taken out and beat
> about the head and shoulders with a large noodle.
I will be *happy* to wield the noodle over the death of LFS, X.25,
and the ISO networking code. Where do I sign up for a noodle?
> If you want all the FS's to *require* the code, then write code for all
> of the existing FS in FreeBSD.
I want them to *eventually* require the code. This is very different
from your characterization of my statements.
> Finally, I disagree with the claim that *all* FS must implement *every*
> vops operation. If so, then the 'stackable' design is broken, since in
> any good design you should have the ability to use a default for common
> operations.
All FS's do *NOT* have to implement every VOP. All FS's do not even have
to implement VOP_{GET|PUT}PAGES, if they don't want to. They can stack
on an FS that implements them (your argeeement with Dima about which
FS that should be is an agreement with me about that), or they can not
offer the services that require the use of the vnode_pager.
> > Terry claims that use of the default vops vector breaks automatic
> > bypass in vfs_init.
>
> Pray tell which existing FS break if you add the code to the default vops?
None. Which existing FS's break if you add stub functions? None. Which
existing FS's break if you make a modification to make the warning not
fatal, the patch for which was included in my last post? None.
Which future FS work breaks by adding the code to the default vops? All
stacking FS's. Which future FS work breaks if you add stub functions?
None. Which future FS work breaks if you make a modification to make the
warning not fatal, the patch for which was included in my last post? Those
stacking FS's stacked on top of FS's which are known to be broken by virtue
of the warning.
> > Dima wants it to work the way it used to, and doesn't see any reason
> > to change the existing code path in a way which is visible to Dima.
>
> Dima (and I) are fans of POLA.
So am I. We are just astonished by different things. I'm astonished
that after 2 full years of effort, FS stacking still doesn't work.
> Terry wants to punish people for not doing things his way.
It's not "Terry's way". I didn't put that comment into vnode_pager.c;
I didn't invent the framework which FreeBSD fails to correspond to.
And the only "punishment" is a perfectly valid warning. Maybe it should
be changed to say "..stale FS code: you will not be able to stack FS's
on this FS!".
> I think reading 20 page emails is punishment enought w/out have the
> FS's break (or whine alot) is overkill.
Sure, demand rationale, and then whine when you get it...
> > Terry claims to have read the comment in /sys/vm/vnode_pager.c:
> >
> > /*
> > * TODO:
> > * Implement VOP_GETPAGES/PUTPAGES interface for filesystems. Will
> > * greatly re-simplify the vnode_pager.
> > */
>
> I don't see anywhere it states that a 'default' VOP_GETPAGES can't be
> added in here, vs. a VOP_GETPAGES in every [ local media ] FS.
It doesn't say I can't include a uuencoded copy of the human genome
database in the damn thing, either, but it would be just as stupid to
do that.
> That's a total non-sequiter. LFS and NFS have brokeness way beyond the
> VOP_GETPAGES stuff. Getting them working require that as well as much
> other stuff. The reason they don't work is that their bits have rotted
> due to inattention.
Software. Does. Not. Mutate.
You as much as agree with me when you suggest "So, if you didn't provide
patches to *all* existing code then you should be taken out and beat
about the head and shoulders with a large noodle."
Point to the brokenness. Apply my patches when I provide them in response
to your pointing. Agree on a definition of "timely", and make it public.
If I do not respond in a timely fashion, back my code out. Pretty damned
simple.
> > For stackable FS's (which means *NOT* local media FS's) the underlying
> > FS below the stack will implement the VOP_{GET|PUT}PAGES by means of
> > the bypass.
>
> So, stacking only applies to non 'local media' FS? Seems like a bad
> design if it can't take care of both cases.
Feel free to enlighten me as to how I may stack an FFS implementation on
top of an EXT2FS implementation.
> (BTW, can you describe succintly what a 'local media' FS is in your
> terms, so that I'm not making any wrong assumptions?)
A file system is stackable if it both provides and consumes the VFS
interface. NULLFS is an example of a stackable FS.
A file system is not stackable if it provides the VFS interface, but
consumes another interface (such as the local OS's VM system). FFS is
an example of a non-stackable FS which consumes another interface.
A file system is not stackable if it does not provide the VFS interface,
even if it consumes the VFS interface. The NFS server is an example of
a non-stackable VFS consumer. The FreeBSD system call interface is another
example of a non-stackable VFS consumer.
Please see section 2.2 of John Heidemann's Master's Thesis for a more
in-depth description of "stackable":
ftp://ftp.cs.ucla.edu/pub/ficus/heidemann_thesis.ps.gz
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803090344.UAA17601>