From owner-freebsd-current Sun Mar 8 21:17:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA29880 for freebsd-current-outgoing; Sun, 8 Mar 1998 21:17:50 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA29875 for ; Sun, 8 Mar 1998 21:17:48 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id WAA25999; Sun, 8 Mar 1998 22:17:41 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id WAA15531; Sun, 8 Mar 1998 22:17:40 -0700 Date: Sun, 8 Mar 1998 22:17:40 -0700 Message-Id: <199803090517.WAA15531@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert 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 In-Reply-To: <199803090459.VAA29017@usr09.primenet.com> References: <199803090356.UAA14668@mt.sri.com> <199803090459.VAA29017@usr09.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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