On Wed, 7 Feb 2001 13:26:20 -0700 (MST), Ronald G Minnich wrote:
>Corrections and comments welcome.
>
>How do we restructure?
>
Basically what you are talking about is just good modular program design really. A
function
does ONE thing and does it well and is directly corelated to its name. For ex you
wouldn't
want to set up the serial port in a function called init_mem();
>We need a sequence of calls to functions to get the bare minimum stuff up.
>What about namespace clashes for multiple superios? Linux solves this
>problems with arrays of structs peppered with #ifdefs (yuck), FreeBSD
>solves it with "linker sets". Another option: Since the config tool is
>told which superios to use, it can easily create the array of structs in a
>.h file which have pointers to the functions for the superio.
Having a struct of calls is probally the only way to handle the mutiple super-io case
with
out a lot of custom hacking. You could then have the calls abstracted out to things
like.
superio[0]->init();
superio[0]->serial_device[0]->set_baud(BD_9600)
The ranges and function names for the superio array and the serial_device array would
be set
from options enabled/disabled in the the config tool options.
We would have to define a device class for any device that needed lowlevel inits.
With the
linuxbios's "only whats necessary to boot linux" creed that really shouldn't be very
many
device classes.
>How do we create main()? If we all write our own main, over time, things
>will diverge, and knowledge I gain in my main() will not propagate to
>yours. Question, should main() be built by the config tool? Just one more
>file to be created using a template and a Config file?
>
I think main() should be completely autocreated from the config file but contain
options to
create some hook functions like pre_[device]_init() and post_[device]_init() to allow
for
some end user customization but still keep an overall structure that's common to all
linuxbios builds regardless of arch or motherboard.
That will make support much easier for the list and make it easier for new
boards/archs to
come up as the examples from one setup will be meaningful to the next one.
--
Richard A. Smith Bitworks, Inc.
[EMAIL PROTECTED] 501.846.5777
Sr. Design Engineer http://www.bitworks.com
