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!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: More on console device (was: Re: Patch for hanging console)
Message-ID: <1993Apr21.071727.8068@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa
Organization: GMD, Sankt Augustin, Germany
References: <1993Apr20.152433.15601@gmd.de> <1r1a5mINNqiu@fstgds01.tu-graz.ac.at>
Date: Wed, 21 Apr 1993 07:17:27 GMT
Lines: 92
In article <1r1a5mINNqiu@fstgds01.tu-graz.ac.at>, chmr@edvz.tu-graz.ac.at (Christoph Robitschko) writes:
|> In article <1993Apr20.152433.15601@gmd.de> Holger Veit (veit@mururoa.gmd.de) wrote:
[...]
|> [ The rest is in fact another thread, about pccons drivers]
Ok, then lets finish the /dev/console debate, and proceed with this...
|>
[...]
|> > This is the situation as is, and it is exactly the problem I am currently
|> > having. It is no problem (hehe:-)) to write a service routine that
|> > switches a particular video card into some video mode, but all of them in
|> > a single kernel would exceed any memory limit (at least the 640k limit:-)).
|> > The probing code itself to detect a card is not that large, and something
|> > like this is already in "codrv".
|>
|> If I remember correctly, the card detection in the old keycap was only to
|> print the card type on coattach. This is a waste IMHO. Can't speak
|> for the newer versions of codrv, though.
|>
It was not only done alone for the nice outlook. Currently the card id is indeed
used for the purpose to distinguish between the EGA-or-better and CGA-Mono-junk
cards. The idea to do card dependent initialisations was the main goal in mind.
A specific fix, for instance is required with the tridents, that interpret
the cursor startline different to all the other boards. Another idea is to
find out in advance (at least for the user) whether X11 might run on this system.
The detection code for the cards is quite similar to the one used in the xserver
(although some upgrade is necessary now). Finally, the kernel provides an ioctl
to retrieve the main card information, which can simplify application software
which needs it.
|>
|> > What is needed are loadable kernel
|> > modules of a specific type: not modules that can be loaded by an
|> > external utility (modload, like on a Sun), but those that are
|> > linked in by the kernel on its own demand. This will lead to a
|> > scattered kernel consisting of several parts, which I found is not
|> > what the BSD purists like (the alternative is a /386bsd.a).
|>
|> I'm not sure what you mean. Why would a modload not suffice ?
|>
|> I'm thinking of something like this: Have a skeleton driver (statically)
|> in the kernel, and in /etc/rc do the following:
|> modload et4000.driv
|> (No card found, not loaded)
|> modload trident.driv
|> (card found, attach)
|> ...
|>
|> What exactly do you mean with "linked in by the kernel on its own demand" ?
The modload approach you describe surely works, but it moves things out of
the responsibility of the kernel. Note that /etc/rc is normally used to
start special user applications, like daemons, or does system checks (like fsck).
/etc/rc is used here in the same way as the DOS CONFIG.SYS, to extend the
kernel's capabilities. We all know that CONFIG.SYS is a complicated
thing for the (non-insider) casual user, in particular with respect to the
sequence device drivers have to be loaded. "Modloading" of, say, 10 video
drivers is quite simple, but it might become more complicated with for instance
file system services. PCFS *could* (but shouldn't!) have stub code to
e.g. support NFS, which requires that NFS must be pulled into the kernel,
which in turn requires at least basic TCP/IP, which needs the "localhost"
pseudo-device or a driver for a network card. A SYSV ioctl or vt100 emulator
module might need to have a video driver successfully loaded before, and
we immediately end up in having complex shell script structures in /etc/rc
that perform loading of modules depending on the return codes of several other
modules. Alternatively, the loadable driver may check itself whether its
preferred environment exists, and fails otherwise. This leaves a simple scheme
like the above in /etc/rc and a confused user in front of the machine who wonders
about the correct sequencing of all the modload lines.
The statement "linked in by the kernel on its own demand" was perhaps an incorrect
expression of what I mean: The kernel itself does probing for all devices, and if it
detects a device, it does not call the code which is statically linked into it
during compile time, but locates the necessary object file from somewhere
(must be specified where "somewhere" really is) and dynamically loads and links it
into its body. This may include a mechanism that a module that has not been accessed
for a long time can be thrown out of the kernel space again (freeing the memory for
paging of applications).
|> Maybe we should move this discussion in comp.os.386bsd.development ?
Good idea. I am curious if my newsreader accepts the patched header;
this reply should appear in *.development now.
Holger
--
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