Subject: Re: Serial consoles: looking for test hardware
To: Jonathan Stone <jonathan@DSG.STANFORD.EDU>
From: None <Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU>
List: port-pmax
Date: 01/16/1996 23:56:18
> CGD's suggestion is to have one static softc element per driver, and
> use that softc for console ports. The autoconfiguration procedure
> needs to be educated to not step on that softc when it comes time
> to try and autoconfigure the serial port that's already running
> as a serial console.
Not really.
The way i do it is to, for each driver that can be console is:
(1) figure out what stuff needs to be used by console stuff
(it's usually a subset of the softc),
(2) make that stuff a seperate structure,
(3) include a pointer to one of those structures in the
softc,
(4) allocate one of those structures statically,
(5) at console attach time, fill in the structure appropriately,
(6) at device attach time, check if the device is the console,
if so point the softc struct element to the static struct,
else allocate a new one.
You don't need to allocate a whole softc's worth of space statically,
and it would be hard (or at least icky) to make the device config code
deal with a statically-allocated softc struct.
You could aruably also include one of the 'vital info' structs in the
softc, as well as a pointer to it, but that too would waste space.
(I also like to keep malloc() allocations smaller, because if you
allocate 1028 bytes, you really allocate 2k, but if you allocate 1000
+ 96 (in two allocations), you end up only allocating 1k and 128
bytes...)
chris