Date: Fri, 12 Jul 1996 14:06:41 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mrm@Mole.ORG (M.R.Murphy) Cc: mrm@mole.Mole.ORG, terry@lambert.org, freebsd-hackers@freefall.freebsd.org, sextonr.crestvie@squared.com Subject: Re: Kernel Config (Was: GENERIC Kernel Debate) Message-ID: <199607122106.OAA01969@phaeton.artisoft.com> In-Reply-To: <199607121530.IAA07385@meerkat.mole.org> from "M.R.Murphy" at Jul 12, 96 08:30:54 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > I think we all ultimately want the all-singing, all-dancing loadable
> > > > kernel modules with PnP detection and auto config of devices while
> > > > simultaneously selecting proper drivers for compatible hardware while
> > > > working around all known incompatibilites.
> > >
> > > Not all of us do. At least one of us wants a really fast, really reliable
> > > system that makes extremely efficient use of its hardware environment. I
> > > suspect that that's not quite compatible with all-singing, all-dancing.
> > > Maybe, but I'm sceptical.
> ^ my spelling for one thing :-)
>
> > What in particular are you skeptical about? Maybe I can allay some
> > of your fears...
>
>
> I've never yet seen an operating system de-bloat. I've never yet seen more
> complicated more maintainable than less complicated. I've never yet seen
> "I'll have this examine the hardware and determine _exactly_ what it is
> and what the user _intends_ to be done with it" work correctly all the
> time. I keep waiting for DWIM, but I'm not holding my breath.
I believe it is a technology issue related to fractal complexity
of software problem soloutions.
To un-technobabble that, "it has to get harder before it can get easier".
The absolute minimal interface for support of boot-critical devices
for everything but network interfaces is a BIOS interface. Network
interfaces can be handled as server (protected mode) ODI, or NDIS
(driver disks come with every interface card). CDROM can be handled
with MSCDEX (again, driver disks come with every interface card and/or
standard interface drive).
A minimal interface soloution gives you the smallest possible fan-out
for a minimal footprint kernel that works with all hardware. This
requires VM86() capability to achieve, at the smallest possible
fan-out achievable for PC hardware.
>From there, you want to start dealing with performance. The ability
to interleave instead of seliazing requests requires protected mode
drivers. Generic poerformance issues (like INT 10 video BIOS disabling
all interrupts instead of waiting for the vertical blanking) require
protected mode drivers. Taking advantage of hardware-specific
acceleration -- requires protected mode drivers.
Q: How do you keep the footprint small?
A1: You load only the drivers for the hardware you have.
A2: You throw away the minimal drivers once they have been successfully
replaced (kernel persistance zone based allocation/deallocation).
A3: You throw away initialization code once it has been run (segment
attribution of multiple segments in a single agregate image).
A4: You throw away code that isn't being used (as long as it is not
used to page in) until it is needed (deinitialization and instance
creation/desctruction for referenced devices).
This gives you a kernel that is smaller than the current monolithic
kernel, since it only contains relevent drivers -- ever. If you
aren't using a device, then it's not in your kernel; it may have been
there an hour ago, and it may be back an hour from now.
>From there, you move onto homogeneous dynamic linking technologies;
this allows you to statically or dynamically link any driver of a
given device support class. We are closing in on this one quickly,
with better effect than Microsoft's "PELDR" VMM.VXD technology, by
using constructors (linker sets) in order to build data objects which
are identical in the static and dynamic linking cases. Some of the
kernel changes in adding the SYSINIT() interface and init_main.c
support are a definite move in this direction.
This saves the world for the people who believe the sky is falling, and
want to build their own custom kernels "for old times sake".
> I tend to like an approach that involves:
>
> 1) a 1-page install document, the first sentence of which
> directs the installer to a reference to be read and understood
> if he doesn't understand the 1-page install document, I don't
> mean just a Xerox(tm) copy of a directory listing with the
> octal code for the bootstrap hand written on the side, but a
> reasonable "Do this in this order" document,
> 2) one diskette/tape/cd/papertape to get the system
> in absolute minimum form to disk, doing what the
> installer asks the installation to do, using command lines
> if necessary, and restartable without having to go through
> the whole thing from the beginning if a mistake is made, and,
> 3) once the barebones system is on disk, configure and
> load away, but don't do it from that annoyingly slow diskette.
> That diskette, that, if I screw up because I'm a doofus, I may
> have to recreate more than once.
Some of these are release engineering issues; most, I would place
in the category of hidden complexity -- you expose fractal order 1,
but you hide fractal order 2, 3, etc..
Right now, fractal layer 2 is the exposed layer: this is why the current
install system requires so many questions be answered to get a default
install working.
By far the biggest problem area is in device management. This devolves
from the fact that the device management paradigm is hetrogeneous, when
it should not be. The management interface for DOS partitioning (a
technology for mapping logical devices to physical media) is different
than the management interface for disklabel (another technology for
mapping logical devices to physical media). The recent discussions
on a management interface for user administraton -- are actually a
perversion of work originally done for a device management interface.
The front-end technology is scalable to problems other than this one,
but that doesn't mean that it excludes this one.
You could argue that this was, technically, an increase in absolute
complexity; but since it orthoganizes the problem, it can actually
be used as a basis for reducing the exposed fractal complexity. It
is a step in the direction of the "one disk, minimal set of questions"
install you are looking for.
Before shouting "too many layers!", note that a logical layering
does not require a corresponding physical instantiation to exist;
the best example is the TCP/IP code, which is logically layered, yet
is monolithic in implementation. A number of STREAMS-based TCP/IP
implementations have moved in the directon of single layering to
avoid the one machine cycle per getmsg/putmsg overhead that physically
layering the logical layers implies. Third part users of the layers
still pay a penalty for not being part of the monolith, but the
integrated code is as efficient as if it were not logically layered,
yet exports rational, orthoganl layering to consumers which need
access at that level.
> If used properly, vi is a reasonable configuration tool.
Reasonable, yes, optimal, no. And I am probably one of the biggest
"vi bigots" you will ever meet in your life. I ported "vi" to
Harris VOS (a realtime FORTRAN/assembly machine), and my coding style
is optimized for use of vi macros for functional cross-reference, etc.
(and people wonder about my "space follows parenthesis" style... hah!
these people obviously are not heavy users of '%' and tags-based
regular experssions).
The vi editor has a fractal complexity of 3, and a complexity of 4
when applied to system files, since the file format must have been
internalized by the person doing the editing.
> Yeah, I'm thinking about putting together an installation that does
> this. Not too hard, but thinking about it. What stops me is that
> I think that a plethora (check my spelling again) of intallations
> a la Slackware, Red Hat, Debian, ..., probably do more harm than good.
I've considered the same thing on more than one occassion; it's a
cop-out soloution to the problem of acceptance -- and you should not
do this unless acceptance proves to be an impossible goal.
> I think the Free/Net/Open split was lamentable.
FreeBSD and NetBSD did not split; they failed to merge. This is a
subtle distinction (though still lamentable). The NetBSD/OpenBSD
split was also lamntable, but both sides believed they had sufficient
cause. You can't force volunteers to work together in an adverse
working environment. Unlike employees, there is no "carrot and stick"
which a central project manager can control.
> This also means I'm not fond of "Now would be a great time to
> register your product." in flashing boxes on the screen with images
> of Lake Washington drifting ever-so-gently in the background, or
> "Here's a hint since you didn't read the documentation." popping up
> every few moments. I'd sometimes just like it to be KISS.
I am torn here. They are a clever way of saying "I am doing something,
and I am making progress, even if it isn't obvious to you". They
are typically used for advertising. But I also know people who take
giddy delight every time Microsoft Developer Studio starts up and asks
them "Did you know that you can...", and tells them about some obscure
feature of the produt it might have taken them months to discover
on their own.
> I watch DG and JD make a really slick VM, but I wonder if it's too
> complicated to really rid of bugs, and I wonder if only 3 people
> understanding it (and maybe not all of it at once) is good, and I
> watch -stable sup have the install procedure updated every night,
> and I wonder about less being better than more. I appreciate
> (emphasize greatly appreciate) the work that those referenced
> directly and indirectly above have done. I just wonder. I hope the
> folks working on it are having fun, heaven knows they aren't paid
> enough or given enough credit for their work.
I think the VM is conceptually more complex, but implementationally
less complex, than its predecesor.
As far as bugs go, there are coding techniques and testing techniques
(ie: branch path analysis) that can result in SQA with little extra
effort. On the other hand, structure and order can make up for a lot
of missing QA. I harp on single-entry/single-exit as one technique;
others harp on using ANSI prototypes. It's possible to produce good
code without either, but it ends up being a more difficult problem,
and requires more rigor to get right. Structural "tools" can be just
as important as source code control tools. The artist in each good
engineer rebels against this, believing that rigor is necessary, that
one must suffer for their art or the result is meaningless.
> I had a 386bsd0.1.2 system up for 450 days running X. I'd'a kept it
> but the new features so outweigh the old that I switched. I'm glad I
> did, but I still wish for simplicity.
In a structure, simplicity depends on the fractal level at which you
view something. If the structure is itself layered, logically laid
out, and designed, then you can look at a higher fractal geometry than
if it were just mish-mashed together. You could take the aparment
building analogy for this: It's possible to make every floor in the
apartment building slightly different (no logical framework). And
it's possible to go to a different contractor for each apartment (no
logical layering). And it's possible to move items from the framework
onto the apartment, like supporting walls (each FS must implement
root mount capability, each FS must implement VOP_ADVLOCK vnode
locking for vclean, each FS must implement calls back into the
kern_lock.c for VOP_LOCK, etc.). Each time you do this, you decrease
the fractal dimesion you must use in order to "get the big picture",
and it's harder to appreciate the architecture for the electrical
fires you are chasing down... it's harder to "get the big picture".
Pining for the 386BSD days is a mistake. It *does* have to get more
complicated to get simpler... it was not possible to simplify the
386BSD fdisk/disklabel process without imposing a complexity-increasing
layer that abstracted the idea of logical-to-physical device mapping
from the specific implementation. If a wall is out of plumb on any
given floor in your building, it effects all other floors above it.
> I'm going to go and take my medication now.
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?199607122106.OAA01969>