From owner-freebsd-current Sun Mar 8 20:59:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26769 for freebsd-current-outgoing; Sun, 8 Mar 1998 20:59:51 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26762 for ; Sun, 8 Mar 1998 20:59:49 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id VAA28986; Sun, 8 Mar 1998 21:59:49 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd028968; Sun Mar 8 21:59:46 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id VAA29017; Sun, 8 Mar 1998 21:59:42 -0700 (MST) From: Terry Lambert Message-Id: <199803090459.VAA29017@usr09.primenet.com> Subject: Re: vnode_pager: *** WARNING *** stale FS code in system To: nate@mt.sri.com (Nate Williams) Date: Mon, 9 Mar 1998 04:59:42 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, dima@tejblum.dnttm.rssi.ru, current@FreeBSD.ORG In-Reply-To: <199803090356.UAA14668@mt.sri.com> from "Nate Williams" at Mar 8, 98 08:56:26 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Can't you diff "all FS's" and "all non-stackable FS's"? > > What's the difference? Aren't all FS's stackable? No. I addressed this later in the posting to which you are replying. > > > 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. > > 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 can send it to you directly, by itself, if you want. I have sent it to Mike Smith, but he might be getting gun-shy about now. I wouldn't blame him. > > 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? The reason they whine is because you won't be able to stack an FS on top of them that required page management services. For example, a quotafs, which must access a hidden file in the FS it is mounted over. > So what's the point in the warning then? See above. [ ... ] > > 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!". > > 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"? This is not an FS devloper issue. How can I tell from above an FS whether or not the FS below me is a stackable FS, or not? 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? The short answer is that I need a "kernel mount flag" to tell me, but that's not a complete answer. I also have to fill in VOPs in my vector from the FS's below me, and propagate them up, the more I mount. That still isn't a whole answer, but it's maybe 80% of the way there, and a useful starting point. 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. They're not useful unless you are stacking FS's, and I haven't provided stacking FS's (yet; I depend on things like veto interfaces and nameifree), so they should be hidden by an #ifdef. > > > 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. > > Bits. Rot. Due. To. Changes. Around. Them. Annie. Get. Your. Noodle. Incomplete changes around them should be backed out if they are not addressed in a timely fashion (the standard to which I am being held, and to which I agree, I *should* be held). Part of this came from having nothing after the USL cease-and-desist, and having to get *anything* that would work, and damn the torpedoes, and I respect that part of it. > 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, if you are arguing with someone who doesn't understand Margo's papers, or the degree to which the code *was* complete *and* functional. Lack of a full-featured "cleaner" is not broken, in my opinion, it's just active research that has yet to be completed. With the Soft Updates not exporting a "dependency resolver registration interface" (there are reasons for this; I've discussed them with Kirk, and neither one of us has been able to convinve the other), an LFS is about the only way you could build a stacking layer that implemented a VOP_TRANSACT. I would *really* like to play with a VOP_TRANSACT. ;-). You *can't* make that claim about Rick Macklem's NFS code. The original breakage there was the addition of cookies to VOP_READDIR instead of some other implementation. The code *was* functional, as provided. It looks as if it's about to be again, thank god^H^H^HJohn Dyson. [ ... why not all FS's are "stackable" ... ] > Thank you. It was nothing. I cribbed it from Heidemann. He's got broad shoulders. 8-). > ps. Even though I am often-times the devil's advocate here, I do > appreciate you taking the time to answer my questions. I'm attempting > to learn wherever I can, and since FS-101 died I'm learning wherever I > can. :) I understand. The still-birth of the FS-101 was a result of impatience on my part. In a lot of cases, I simply don't have the context in common that I would need to boil things down. That's why I'm always referencing papers. I've taught some University classes, but I'm willing to admit that I wouldn't be good at starting from ground zero and building a reasonable justification. I tend to point at papers that I think would do a much better job of it than the hash I would make of things. 8-). 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