Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!uwm.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!unidui!du9ds3!veit
From: veit@du9ds3.fb9dv.uni-duisburg.de (Holger Veit)
Newsgroups: comp.unix.bsd
Subject: On patchkit and large fixes (was: XFree86...)
Date: 17 Nov 92 07:54:18 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Lines: 111
Message-ID: <veit.721986858@du9ds3>
References: <veit.721670337@du9ds3> <STARK.92Nov14094333@sbstark.cs.sunysb.edu> <veit.721901127@du9ds3> <1992Nov16.222149.4904@fcom.cc.utah.edu>
Reply-To: veit@du9ds3.uni-duisburg.de
NNTP-Posting-Host: du9ds3.fb9dv.uni-duisburg.de
In <1992Nov16.222149.4904@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>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:
[...on "codrv", an alternative console device with (currently) emphasis on
X11 support, integration into the patchkit, and patches pending...]
>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.
Most of these 50-60 patches, I mentioned were already published in c.u.b.,
so you should be aware of them. The essential patch that is included in
the codrv package, fixes the problem that pty's are further used after
closing the device, causing the console to hang after return from X. I sent
this fix to Nate, but even with the enclosed explanation it seems nobody
has ever done something with it. This may be because of the "confusion"
you mentioned above.
>>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.
I agree completely. I offered this driver to the community, because I think
that it is an improvement over the existing one. It is quite natural to defend
one's own work, but I don't force anyone to use it. Normally, there is
"no problem" to replace one ethernet driver with another for the same board,
and it is strongly recommended to take the one with the highest throughput.
This holds for SCSIand other disk drivers as well. The problem with the
console driver is a bit different: There may be - and there are - a number
of builtin functions (ioctl's) in particular, which must be there for
some important task, but unfortunately make software that uses them very
driver dependent. It is unfortunately not possible to extract some good
feature, such as font loading, from codrv, without also taking part of
the ESC-sequence handler (because font switching uses ESC codes). For some
things this works: the "Setbell" or "keyboard LED" code fragments are
quite independent. No problem to build a patch to insert this into pccons,
but this fix will be in there forever. In the long term you might get
a "pccons with old X support and bells and whistles", one with VT100 emulator,
one for X11, one with multiple virtual screens, etc. I would not maintain
a user application which must first detect which driver it has, and then
enable or disable special features.
>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.
Codrv carries the old pccons with it (with an encapsulation, that allows
building a kernel with only one of codrv and pccons), the original patches
(with some interleave) can still be applied to this file.
> 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.
I also heard of Bill's plans, but it is to early to decide now what will
go and what won't. Truly loadable and unloadable modules could help
(Regarding the former discussion on that topic, I am beginning to change
my opinion, don't be surprised).
>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.
I would also consider this to be a fine extension.
>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
>-------------------------------------------------------------------------------
Holger
--
| | / Dr. Holger Veit | INTERNET: veit@du9ds3.fb9dv.uni-duisburg.de
|__| / University of Duisburg | "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| | / Dept. of Electr. Eng. | Sorry, the above really good fortune has
| |/ Inst. f. Dataprocessing | been CENSORED because of obscenity"