Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!newsserver.jvnc.net!gmd.de!fanoe!veit
From: veit@fanoe.gmd.de (Holger Veit)
Subject: Re: 3C501 Ether driver, XS3+codrv
Message-ID: <1993Mar11.090535.9238@gmd.de>
Sender: veit@fanoe (Holger Veit)
Nntp-Posting-Host: fanoe
Organization: GMD - German National Research Center for Computer Science
References: <1993Mar2.114020@sun6.lri.fr> <1993Mar5.132206.15422@gmd.de> <1993Mar9.043947.4016@netcom.com> <1993Mar10.213242.423@netcom.com>
Date: Thu, 11 Mar 1993 09:05:35 GMT
Lines: 67
In article <1993Mar10.213242.423@netcom.com>, thinman@netcom.com (Technically Sweet) writes:
|> I would suggest instead that you get the simplest possible
|> console driver and put all the card management issues into
|> a separate console daemon. Possibly, the 'screen' program
|> that manages several text banks. Then, create a screen
|> painting library that the daemon exports which sets the
|> screen type to graphics or text, switches screen banks,
|> and paints the screen.
'screen' was always a good example for me of how things could work.
Unfortunetely, from a number of mails, there seemed to be consensus,
to have "virtual terminals" with real login (I believe just because
all the other UNIXes have them as well).
Things that just deal with the tty driver input and output can be
excluded easily; this is one reason why I have not yet a super-duper
VTxyz terminal emulator in the kernel.
But there are more things, that cannot be done outside the current
kernel without problems. One is I/O and interrupt handling. There is
a hack to give the xserver the privilege to access I/O but
this imposes at least significant security leaks, if not stability
problems. The way it is done in this context is not recommended in
general.
Setting screen modes, detecting video cards are exactly those tasks
that require special privilege, and have to be done in an early
phase of the startup (when user applications are not yet executable).
My idea is to load these and other parts on demand, so the kernel won't
be filled up with stuff for all environments. This will lead to a
somewhat 'lean' kernel. One might argue that a kernel that loads
all the things in again afterwards is quite the same like a large one
with the necessary things already in, but one should not forget
that the same amount of space would be occupied by user servers
performing these tasks. My opinion is in contrast to yours (below):
If there are things that need special privilege or do things a
normal user application should not do (things that might affect
other processes unintentionally), they should remain
behind the kernel shield.
|> My 12 years' experience in Unix kernel work yields several
|> maxims, I will only bore you with one: if there is a choice
|> between placing features in the kernel and placing them
|> in a program, always place them in the program. Always.
|> No exceptions.
If we had a kernel architecture which truely allowed moving parts
of the kernel out of it (similar to the Mach system), I would
fully agree. But we haven't yet.
|> P.s. another one: don't use badly designed hardware.
|> The 3C501 comes to mind.
Seconded.
Holger
|>
|> --
|>
|> Lance Norskog
|> thinman@netcom.com
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions