Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!agate!netsys!decwrl!sun-barr!cs.utexas.edu!sdd.hp.com!caen!sol.ctr.columbia.edu!eff!news.byu.edu!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: XFree86 problems (keyboard hangs overnight)
Message-ID: <1992Nov16.222149.4904@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <veit.721670337@du9ds3> <STARK.92Nov14094333@sbstark.cs.sunysb.edu> <veit.721901127@du9ds3>
Date: Mon, 16 Nov 92 22:21:49 GMT
Lines: 84
In article <veit.721901127@du9ds3> veit@du9ds3.uni-duisburg.de writes:
>In <STARK.92Nov14094333@sbstark.cs.sunysb.edu> stark@cs.sunysb.edu (Gene Stark) writes:
>Codrv is indeed a new package, which is, like other software (see buglist.0.9),
>not directly integrated into the patchkit line. But as I said, if you
>omit the "pccons" related fixes of the patchkit that come along some time,
>there are no problems with codrv, in contrast to ports and modifications,
>which are based on "pccons". There is a tradeoff between new features and
>portability. However, I must admit, that the way of installation, that is
>used now in keycap, is not very user friendly. This marks a general problem
>with the patchkit: It must be maintained from a central side. I currently
>have about 50-60 patches pending, which are not yet covered by the patchkit,
>some of them are important in my area, one is included in the keycap-kit.
>Should I wait forever until the fixes will flow into the patchkit?
I agree that the general problem with the patchkit is the centralized
maintenance. Thus the same thing that gives it it's strength (the ability
to coordinate multiple patches to the same files and insure patch
precendence ordering) is it's greatest weakness (centralized control, or
at least the handing around of a "magic cookie" [token] to ensure consistant
ordering and patch number assignment).
The patchkit grew out of one night of frustration in trying to install
several fixes to kern_exec.c. I believe that using a patch kit patch
mechanism is still superior to the alternative, which includes having to
manually install all but the first patch to a file, no ability to gracefully
back out a patch (unless you keep your own diffs on the manual installs),
and having the patches "blessed" by installation/deinstallation/stability
testing.
By all means, send your 50-60 patches to Nate or myself, or put them on
ref.tfs.com, and we'll grab them! I think the long delay in putting out
new patches has beenlargely due to Nate and I being confused
over who's going to integrate patches first.
>The idea of codrv was the avoidance of these "small, reliable patches".
>Natural growth of software was rarely a good base of software development.
>You might not need keyboard overloading, others might, you may require
>bell and keyboard fixes, others do not, but they might want to have other
>"bells and whistles". So how would you find an integration platform (I
>guess you won't, or at least haven't thought about it yet)? Codrv is
>a product for the future, not for current restricted requirements. This is
>why it has been marked "incomplete".
This touches a sacred cow of mine, which is configuration. There is
absolutely no reason why you should not be able to pick one of several
console drivers, several of many ethernet drivers, or one or more disk
drivers from those available.
It should be possible to run "codrv" and still maintain the current
patch level of pccons without effecting it adversely (or even using the
pccons code at all if you don't want to. SVR4 definitely has Berkeley
beat in this area; at a minimum, the files.i386 file ought to be
created from a set of specific "drop in" files to allow drop in (if not
drop out) of new driver/file system modules. Some of this is apparently
being addressed in 0.2 from what I hear, but loadable modules don't go
sufficiently far in this direction.
It's true that good software tends to be revolutionary instead of
evolutionary (exceptions for BSD and vi 8-)), and there should be some
kind of non-conflicting drop-in mechanism for new kernel subsystems
(like codrv). I'm not suggesting a "micro" kernel, but a layered
approach couldn't hurt. One thing I'd like to see is a binary command
line configurator so that, unlike SVR4, we don't have to rebuild all
of our "space.c" equivalents each time.
Another thing that would help is a packaging/versioning tool, such as is
provided by SCO, and a logical break-up into "packages" (other than etc,
bin, and src) for the software we normally see on 386BSD.
Meanwhile, keep posting/uploading/mailing/ftping patches until we (the
users of 386BSD) can get something more permanent worked out.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------