Date: Fri, 13 Oct 1995 17:48:54 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Terry Lambert <terry@lambert.org> Cc: julian@ref.tfs.com, jhay@mikom.csir.co.za, hackers@FreeBSD.ORG Subject: Re: IPX now available Message-ID: <911.813631734@time.cdrom.com> In-Reply-To: Your message of "Fri, 13 Oct 1995 17:14:39 PDT." <199510140014.RAA18659@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> [ ... 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?911.813631734>