Re: split biosfs.c into several XDD's?

[itschere@TechFak.Uni-Bielefeld.DE]

 Huhu!

> Ok, but I think we should have a core set of drivers inside the kernel.
> console.xdd is one of them, the (to be written) acsi/scsi xdd another one.
> Otherwise, how could MiNT inform Joe User about non existing path for loading
> xdd's? Or about serious problems while starting?

 In this case I wouldn't mind MiNT using the BIOS, but that's a question of
when the new drivers are installed. Obviously, you could either leave the
original BIOS-devices (would be easier, perhaps) or the new driver in the
kernel, if the biosfs is changed in a way that it allows to completely
replace a driver (for root only, of course).

 Hmmm, in this case, I would prefer leaving the (old) devices as they are, so
MiNT can happily use them for initialization output and supply XDDs to
eventually replace them. Looks like the code will only get bigger at the
beginning, but then, if we can rely the drivers being replaced, you could
cut them down to some *very* basic code, say, without select() stuff, which
isn't needed at this time.

 Another point: For purposes of external device drivers the time/date values
should perhaps be made accessible over the kernel pointer, so that the driver
must call any Tgettime() or so.

> How about writing a keyboard.xdd, too?

 I was thinking of even merging the console with the fasttext driver, and
you suggest splitting it? :-) Honestly: What should be the advantage of that?

> In fact each of these xdd should be a possible part of the kernel to build
> a version of MiNT which boots from the network. This will result in a
> configurable kernel...

 Ok, real XDD are perhaps not needed. It would perhaps be enough to split
the code into several parts, but leave them in the kernel, if it's just a
question of how to encourage people to support them, and exactly that's the
thing I intended to do, so I really don't know what I'm mucking here... ;-)

 Hey, I think that's perhaps the best and easiest idea!

> And another one: How about integrating Juergen Lock's vcon (Virtual Console)
> into the kernel?

 As far as I know he hasn't done this so far (or suggested to do so) in order
to have better possibilities to maintain it. But it would of course be a good
idea to do so, as soon as he thinks it's stable enough.

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