Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!darwin.sura.net!newsserver.jvnc.net!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: Console Driver
Message-ID: <1993Jun17.153500.28625@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa
Organization: GMD, Sankt Augustin, Germany
References: <1v9nrdINN412@gap.caltech.edu> <2380@hcshh.hcs.de> <DERAADT.93Jun12232325@newt.fsa.ca>
Date: Thu, 17 Jun 1993 15:35:00 GMT
Lines: 69
In article <DERAADT.93Jun12232325@newt.fsa.ca>, deraadt@fsa.ca (Theo de Raadt) writes:
|> In article <2380@hcshh.hcs.de> hm@hcshh.hcs.de (Hellmuth Michaelis) writes:
|> > Yes, its taking place. There is a mailing list moderated by Julian Elischer and
|> > 10-15 people (including the authors of syscons, codrv and pcvt) from all over
|> > the world participating.
|>
|> I think I should add my list of highest priorities for this.
|>
|> 1. vtXXX support. The "pc3" emulation has got to go for a number of reasons.
|> (Yes, this is #1 for me.)
Playing a little bit a speaker for the console group...
This *will* certainly be done.
|> 2. codrv-like X code.
Depends on the interpretation what the codrv-like X interface really is.
There will be seperated /dev/kbd and /dev/vga like in codrv, but it is
not yet fixed whether to adopt the special codrv way of interaction.
We are also discussing the SVR4 vty style here. The XFree86 people on the list
could live with any solution, but there is preference to allow switchable
xservers in a vty, which sounds interesting and could be done with the SVR4
VTYs (Adding other SCO/SysV ioctls have been discussed quite controversely,
however).
|> 3. /dev/console vs. /dev/vga with syslog problem solved.
Of course.
|> 4. fast. for instance, i believe that currently the pccons driver in NetBSD
|> is probably one of the fastest.
There are certainly things to optimize in any other driver, but this is
certainly not first priority (perhaps not even fourth) in our schedule.
|> 5. There are a bunch of functions which were being called by the rest of
|> the kernel. Any that are not needed for a regular device driver, or for
|> console sub-driver should be made static. *everything* must go through
|> the console calls (ie. serial console.)
We would like to have a detailed list of things you would like to see
removed/moved to elsewhere for e.g. the pccons driver, such like
sgetc(), pg(), Crtat etc. in order not to propagate the old hacks into the
new driver. Please send such a list to the coordination account at
console@jules.dialix.oz.au.
|> > But, (and thats my personal opinion) it will last some time until this gets
|> > ready, don't expect anything before the end of the summer ...
|>
|> I hope before then. That timeline is too long. Long before then, others
|> will have settled on something else. My advice, unfortunately, is hurry
|> up or give up. I wish the best though.
|> <tdr.
This should be a well planned project, not yet another hacking session all
existing console drivers still suffer from. This requires time to speak
about certain things and then implement. We don't care about other attempts
to throw something on the market, and we ignore any pressure from elsewhere
to get something working fast. The situation is not that there is
nothing available at all.
--
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