[9fans] plug and play woes

[9fans] plug and play woes

[jmk]

pnp is just a waste of time. if the bios allows, just turn it off.

there is a .exe form of b.com although the current b still fits in
the 64K limit.

i don't see a problem with moving more of the grunge configuration work
into the bootstrap on the pc. i laid the groundwork for this and actually
started coding it when i added multiple processor support; since i had to
shuffle the low memory placement anyway i left room for such stuff. another
unfinished project, however.

[9fans] plug and play woes

[David]

> I've been reading the last month worth of 9fans
> after being away.  Why not do most of the plug and
> play stuff in b.com to initialize IRQs, etc., and
> then load the kernel with appropriate plan9.ini lines
> generated for it?  Thus, the code that has to
> worry about plug and play drops out of memory as soon
> as the OS starts, and the kernel doesn't have to be
> bothered.  Note that I distinguish between plug and
> play (PnP, the much-hyped garbage that your BIOS does
> to you every time you boot) and cards that ``autoconfigure''
> like 3Com cards and SoundBlasters.  I'm not sure if this
> distinction is a valid one.  Perhaps autoconfig stuff
> should be done in b.com as well...  Just my 2¢.

It's a possibility which has occurred to me...  At this stage,
it's convenient to have all this stuff in the kernel for
debugging -- when something goes wrong, you can keep around
enough state to figure out what happened.  But maybe this
code should be moved to b.com later, along the lines that
you suggest.  b.com will have to do PnP anyway if we want
to be able to boot from the network using PnP ethernet
cards like my silly "ne2000 compatible".

At some stage all this extra bloat will probably force
b.com over the 64K limit for .com files (don't you
just _lurve_ DOS?).  I'm not sure what the answer to that
one is; maybe we have to convert to "b.exe"?  (Yucko).

Anyway, there's plenty of time to think about that one,
because the PnP code has a fair way to go before it can be
considered robust...

[9fans] plug and play woes

[rsc]

I've been reading the last month worth of 9fans
after being away.  Why not do most of the plug and
play stuff in b.com to initialize IRQs, etc., and
then load the kernel with appropriate plan9.ini lines
generated for it?  Thus, the code that has to
worry about plug and play drops out of memory as soon
as the OS starts, and the kernel doesn't have to be
bothered.  Note that I distinguish between plug and
play (PnP, the much-hyped garbage that your BIOS does
to you every time you boot) and cards that ``autoconfigure''
like 3Com cards and SoundBlasters.  I'm not sure if this
distinction is a valid one.  Perhaps autoconfig stuff
should be done in b.com as well...  Just my 2¢.

Russ