split biosfs.c into several XDD's?

[Torsten Scherer <itschere@TechFak.Uni-Bielefeld.DE>]

 Hello world!

 Yesterday (all my troubles seemed so far away... :-)) I've had the dream
of splitting the biosfs code into XDD's for each possible device. The
biosfs.c has steadily been growing until now it's almost the biggest file
in the source. In my eyes, things are much easier to maintain or upgrade
if they come in smaller files. Besides that, it's not necessarily the
job of the filesystem code to provide all the necessary device driver
code.

 You might think: Oh, why that? Wouldn't that result in having several
copies of almost identical code, one for each device? Well, you're right,
but I'd like you to understand it as a first step to get rid of the old
drivers using BIOS calls. If you've got a seperate driver for each device,
you can easily maintain it, which for now isn't possible at all, since the
console and the modem drivers share the same code.

 Even if all of them would still use BIOS code for the beginning, it would
already be possible to do things like selectable modem devices in a perhaps
more comfortable way using Kay Roemers addroottimeout() patch than it was
done before. Or make modem devices better respect ^S/^Q for example.

 This would result in having the following device drivers (not all of them
for every type of computer, but that should be a job of the initialization
code then), with some notes about possible changes I've been thinking of:

console.xdd
midi.xdd - shouldn't forget that :-)
modem1.xdd - switch to new (unix-style) names?
modem2.xdd - dito?
serial1.xdd - dito?
serial2.xdd - dito?
centr.xdd - switch to a proper name, say, lp.xdd? would make it easier to
		*replace* it with Thierry Bousch's one
fasttext.xdd - perhaps merge this with console.xdd and use some fcntl to
		switch between them?
null.xdd
mouse.xdd - add an absolute mode? the small buffering of relative steps
		makes - for example - MGR crawl like a snake when the system
		is under heavy load, making the buffer bigger wouldn't do,
		but adding an absolute mode (errr, not SUN compatible)
		speeds up mouse pointer movement dramatically

 My current understanding of which chips drive which device is this:

	| modm1	| modm2	| serl1	| serl2 (LAN)
--------+-------+-------+-------+------------
ST/STE	| STMFP	|	|	|
MSTE	| STMFP	| SCC-B	|	| SCC-A		(a bit unsure about SCC-A)
TT	| STMFP	| SCC-B	| TTMFP	| SCC-A
Falcon	| SCC-?	|	|	|		(and the other channel?)

 So the problem is that the modem1 driver must contain code for both
different hardware in order to provide the same device on any computer.
On the other hand, a driver named after the hardware it supports must
install it with different names, depending on the computer it runs on.
Since this shouldn't be very difficult (use cookies) it seems to be the
better solution to me. So this would result in three drivers:

stmfp.xdd
ttmfp.xdd
scc.xdd - anyone wanting to write a sccdma.xdd???

 Everybody keeps talking about the day we'll finally get rid of the old
BIOS drivers, but nothing constructive has been done so far, except Thierry
Bousch's drivers, but not everyone uses them so far.

 So what do you think about this? I wouldn't like to start working without
knowing it has got any chance. :-)

ciao,
TeSche
--
Torsten Scherer (TeSche, Schiller...)
Faculty of Technology, University of Bielefeld, Germany, Europe, Earth...
| Use any of "finger itschere@129.70.131.2-15" for adresses and more.	|
| Last updated: 14. April 1994.						|