From owner-freebsd-hackers Fri Jul 12 14:12:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16623 for hackers-outgoing; Fri, 12 Jul 1996 14:12:27 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA16613 for ; Fri, 12 Jul 1996 14:12:23 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01969; Fri, 12 Jul 1996 14:06:41 -0700 From: Terry Lambert Message-Id: <199607122106.OAA01969@phaeton.artisoft.com> Subject: Re: Kernel Config (Was: GENERIC Kernel Debate) To: mrm@Mole.ORG (M.R.Murphy) Date: Fri, 12 Jul 1996 14:06:41 -0700 (MST) Cc: mrm@mole.Mole.ORG, terry@lambert.org, freebsd-hackers@freefall.freebsd.org, sextonr.crestvie@squared.com In-Reply-To: <199607121530.IAA07385@meerkat.mole.org> from "M.R.Murphy" at Jul 12, 96 08:30:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > 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.