Date: Mon, 9 Mar 1998 07:21:25 +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: <199803090721.AAA04670@usr09.primenet.com> In-Reply-To: <199803090517.WAA15531@mt.sri.com> from "Nate Williams" at Mar 8, 98 10:17:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. OK. The point is that Dima's argument is based on an assumption that I hadn't meant to imply (but did, in all fairness). > 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. The actual intent of the Heidemann code is that it would still work. There is a problem here in that linker sets are agregated statically instead of dynamically. Some of this requires both ELF and a change to the way we handle linker sets to fix. Specifically, if you look at Heidemann's requirements, then the decriptor structure ought to be built up using linker sets. I haven't committed this change yet. The issue here is whether you can dynamically extend the contents of linker sets or not, in order to meet Heidemann's design goal of dynamic VOP extension. Pretty much, when the linker set is extended, you need to make a callback that causes the allocated vector for the mount instance to add the VOP. > > 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 need to look at the kernel mount flags. This is essentially what I told Poul. THe work needs to be domne in vm_mmap. > > 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. Sorry about that. Sean has his head screwed on straight with regard to making the obvious obvious. He's a good translator for this type of thing. Like I said before, I'm no Ronald Reagan (great communicator). As John Dyson put it, I'm a better researcher than contributor. 8-(. > 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. Yes. This is different from interfaces. which are allowed to be "pure virtual" base classes. I wasn't sure about using OO terminology. 8-(. > > 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. OK. I agree that there were some endemic problems that Rick solved. The distinction here is beteen code from a "trusted" source and not. Rick was trusted, so the code was assumed OK (may or may not be a "bad" thing, but the difference is between OEM'ed code and trusted code: if it came from 4.4, it's assumed to be "OK" kind of by definition). > 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. Sean's a better communicator than I am. I wish I were better, but if I had to make a choice between being a better communicator or what I am, I'd have to (sheepishly) choose what I am. Like the scorpion, and the crossing of the river, it's my nature. Anyway, thanks to Sean... 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803090721.AAA04670>