Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 8 Mar 1998 22:17:40 -0700
From:      Nate Williams <nate@mt.sri.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        nate@mt.sri.com (Nate Williams), dima@tejblum.dnttm.rssi.ru, current@FreeBSD.ORG
Subject:   Re: vnode_pager: *** WARNING *** stale FS code in system
Message-ID:  <199803090517.WAA15531@mt.sri.com>
In-Reply-To: <199803090459.VAA29017@usr09.primenet.com>
References:  <199803090356.UAA14668@mt.sri.com> <199803090459.VAA29017@usr09.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> > > I want them to *eventually* require the code.  This is very different
> > > from your characterization of my statements.
> > 
> > Right now they *require* the code.  If they don't have it, they whine
> > and sometimes misbehave.
> 
> See the patch in the posting that you initially responded to.

I responded to a posting by Dima, not by you, so there was no such
patch.  I was just trying to understand the argument from both sides.

> > > 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.
> > 
> > If they don't have to, then why do they whine if they don't have it?
> 
> Because you have not applied the patch?

And that patch adds the GET|PUT{PAGES} code into all existing local
media FS's, right?  Then my argument is now moot.

> > It's violates POLA.  A normal user of FreeBSD doesn't have any stacking
> > FS, and he's seeing irrelevant/whiney messages that imply something bad
> > about his system, when in fact there are no problems with his system.
> > (There are potential problems, but if he's writing stackable FS's, then
> > he should be smart enough to figure this out, shouldn't he?)
> 
> What if he's downloading binary modules and installing them, expecting
> them to "just work"?

If the binary modules were compiled against FreeBSD, then they wouldn't
'ever' work since FreeBSD is broken in this respect per your arguments.
Anyone providing said 'binary' modules would be stilly for providing
broken code to users.

> How can I tell from above an FS whether or not the FS below me is a
> stackable FS, or not?

Actually, I was wondering this very question myself?  How can I tell if
the FS below is stackable?

> If it is, I can look for the VOP's; if it isn't, how can I know if
> needed services are provided or not?

You tell me.

> I'm willing to bow to pressure to get some silence.  I've discussed
> this with Mike Smith, and the console warnings should be going away.

Sean Fagan explained to me the crux of your argument off line, and once
it was put so plainly and simply to me I agree that what you are doing
is *a good thing*.  But, trying to wade through the noise has been
difficult.

In short, you are attempting to make local media FS's the 'base class'
for all FS (using C++ vernacular).  As Base Classes, they must
implement/define *everything* for all classes, and that all other
'stackable' FS's can inherit from the base class.

[ NFS and LFS were broken ]

> > They were broken when we got them.  Their brokeness continued and was at
> > times made worse due to changes made around them.  If they had been used
> > by someone, then they would have been maintained.
> 
> You *may* be able to make this argument about LFS

...

> You *can't* make that claim about Rick Macklem's NFS code.

Sure I can.  Rick has posted some patches to the NFS code that we've
integrated, and there are obvious bugs in the way the code originally
did things in the 4.4BSD that caused problems.

In any case, I'm in agreement with you now.  I only wish it were
possible to distill the description of what you are saying with a lot
less volume.


Nate

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?199803090517.WAA15531>