Date: Fri, 13 Oct 1995 18:40:56 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, julian@ref.tfs.com, jhay@mikom.csir.co.za, hackers@FreeBSD.ORG Subject: Re: IPX now available Message-ID: <199510140140.SAA18883@phaeton.artisoft.com> In-Reply-To: <911.813631734@time.cdrom.com> from "Jordan K. Hubbard" at Oct 13, 95 05:48:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.. :-)
8-).
> > 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.
The file system stacking interface isn't really succeptible to anything
short of runtime code generation if you want to split out depedent
modules from depended on modules.
I know this for a fact: I am loading the file systems as individual
components using the Win95 PELDR_* interface, and I am well aware of
exactly what I had to do to make it work. For the Win95-non-literate,
the PELDR_* interface is the VXD equivalent of a DLL. It uses runtime
patched function indirection vectors, and can suuport variable references
through linker magic and storage class attribution using the __declspec()
identifier previously discussed.
> 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.
I would be loathe to give up file system stacking, especially when we
are on the verge of being able to finally use some of the technology
to our advantage in BSD. Particularly with the advent of devfs.
John Heidemann spent enough time to get a Master's degree on the file
system stacking, and I would be very careful modifying it without as
much thought. Most of the recent stuff I've done has been in regards
to corecting the way it was haphazardly pounded into the BSD 4.4-Lite
I think that you missed a private exchange between Julian and I early
on when this discussion was getting ready to boil. A stacking interface
is also planned for use in the device file system itself for exportation
of logical devices, which may be simple translations of physical devices,
all the way up to an "extended partition" inthe DOS sense with an "extended
partition" in the BSD sense on top of it (what we call a "disklabel").
We can not hope to eliminate stacking interfaces without losing the
ability to operate cross-architecture.
Someone was recently asking about mounting NeXT disks. Part of that is
a physical-to-logical device translation mechanism that is applicable
to the way NeXT does disk slicing. Potentially, another one would
replace that in place to implement NeXT's idea of "media perfection".
Finally, a logical device is exported in the devfs to the file system name
space, and that is mountable by a file system. This can use the stacking
of logical device translation layers 2-3 times (depending on partitioning
below slicing) before a logical device, consisting of a strategy routine,
a start sector, and a length, is exported for use by a file system,
Then the file system specific issues begin.
[ ... ]
> I don't doubt that there is a performance penalty to be paid.
[ ... performance "hairy dog" story elided ... ]
> 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.
Scalar variables are actually the least frequently address referenced
objects crossing logical interface boundries in the kernel. I've
compiled the whole kernel (almost) on a PPC using the AIX C compiler
and imports and exports at the interface abstraction layer to ensure
that the interfaces were clean. This is actually where I identified
the cn_pnbuf issue that was recently put to bed after two patches,
but not yet committed.
The point is, that most of the issues to be resolved are structures
containing function pointers. The one exception is the structures
containing op descriptors in the VFS, and that's easily resolvable
even without reordering using a slightly more complicated kern/vnode_if.sh
script and manifest constants, with a descriptor post-process insertion
routine (one place where I would find it acceptable) that traverses
the ops list replacing the descriptor indices with the descriptors
themselves.
Meaning most data is not accessed across interface boundries, mostly
it function addresses.
> 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.
I agree, I don't see this as a serious limitation in coming up with a
set of changes. My last interface patch touched 17 files. It's a
limit of the programmer having to do it all at once.
> 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 think this is in error. I think we are all defining where those chalk
marks lie, after which, as long as the definitions are broad enough, any
work within the chalk marks will not be cramped.
I am very against the "hack on hack" approach. I think CSRG's approach
to wiring in the VFS falls right into this category, and it's something
that we are even now working on correcting. We aren't under the
crippling constraints that they were under in terms of needing to
rewrite the world from scratch to prevent dubious claims of "contamination",
and needing to do so in a very short period of time.
By the same token, anything that works is better than anything that
doesn't. It's important to design revolutionary, but to implement
eveolutionary. The common shortcut of designing evolutionary should
be outlawed.
> 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! :-)
I'm not willing to shuck much of "the UNIX legacy". If you want to
work on something other than UNIX or a UNIX clone OS, feel free to
do so. But it won't be UNIX.
I agree for the most part with the idea that we have inherited some bad
code, but I'll be damned if I'll condemn the ideas that caused that code
("the UNIX legacy") without a fair hearing. 8-).
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510140140.SAA18883>