From owner-freebsd-hackers Fri Oct 13 17:50:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA19240 for hackers-outgoing; Fri, 13 Oct 1995 17:50:51 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA19227 for ; Fri, 13 Oct 1995 17:50:47 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id RAA00913; Fri, 13 Oct 1995 17:48:55 -0700 To: Terry Lambert cc: julian@ref.tfs.com, jhay@mikom.csir.co.za, hackers@FreeBSD.ORG Subject: Re: IPX now available In-reply-to: Your message of "Fri, 13 Oct 1995 17:14:39 PDT." <199510140014.RAA18659@phaeton.artisoft.com> Date: Fri, 13 Oct 1995 17:48:54 -0700 Message-ID: <911.813631734@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > [ ... definition elided ... ] > > (comment: I think "readOnly" is a bit? So it should be stolen from "type".) Actually, you don't even need it at all - I just included it as a convenience. You could simulate read-only by simply redirecting the put function to a stub which disallowed it. Hmm. Didn't make any provision for put() returning a status! Whoops! :-) > The use of indirect references is at best, an unpleasent overhead > addition, and at worst, completely unworkable. Well, I guess that kinda makes your position on THAT clear.. :-) > The INDIRECT you add above would require the use of dual-stating the > external declaration in the header files (the most likely soloution), Actually, no. I guess I didn't make it plain enough that I'd expect the mountain to come meet Mohammed to a certain extent with a scheme like this - you'd need to substantially reimpliment the interfaces between the VFS code and an LKM using it, as you mention, as well as a host of other things. I think you're still in the mode of "loader replacement" whereas I'm talking more "paradigm shift" where we stop writing dual-role drivers (static and LKM) the way we do now and start thinking more fundamentally about how the kernel talks to external devices, filesystems and other features. Nothing you do with the loader or a replacement for the loader is going to deal with the problems of changing interfaces, and the indirection scheme does at least buy you that. > the test case, it was TCP, UDP, and IP. Their results speak well for > seperating logical interface design for abstraction implementation in > favor of efficiency. See Julians's recent post for collaborative > speculation on overhead for protocol family based dispatching). I don't doubt that there is a performance penalty to be paid. I once worked for a company that had a product called "X.DOT" - one of the first commercially available X.25 packages you could buy if you were a manufacturer of custom X.25 switching hardware (there were a few. :-). Anyway, reports started coming in from the first BETA customers that they were only getting some 20% line utilization - the hardware was simply running out of woof long before maximum theoretical efficiency was reached. Well, they looked at the code and they looked and it and they realize that it was some BEAUTIFULLY written code; everything abstract to the nines and layered at all the logical layering points and basically a paragon of virtue (or is that WIRTHue?) with the one tiny flaw being that it didn't work. It was TOO well layered, TOO well abstracted. To put it colloqually, it crawled on its belly and barked like a dog. So they had to go in there and do some really horrible hatchet work that I'm sure the original author still feels to this day, and yes, I'm aware of the penalties of going too far into the abstract. That's why I suggested that not *everything* be done through the indrect pointers and you have the variable_{get,put} routines trying to be reasonably smart about returning simple scalar types for which no special handling is required directly from the variable (and I expected the list of such types to be added to). That'd leave the hash lookup as the most expensive part of the operation, and I know of some that are pretty fast. But all considerations of efficiency aside, I still agree that you can't take the full range of interdependencies represented by our current LKM/kernel mix and fit it easily into this model - not by a long shot. Maybe what I'm really saying here is that if we're going to go with dynamic everything at some point in our future then we should at least be willing to look at as many other approaches as possible before diving in and trying to patch what we have now. Working within the existing chalk marks has many definite advantages, and sometimes it's the ONLY way to get something actually done, but it can also frequently quality for the "hack on hack" category and what you end up with at the end of your 5 year plan is a big Mess. I dunno. There's a lot that's broken with the code we've inherited (and the UNIX legacy in general) and maybe it's just that I don't see anywhere near enough heretical discussion in this mailing list to make me feel comfortable that people are really owning up to it! :-) Jordan