From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon,  4 Aug 1997 11:21:16 +1000
From: David Hogan dhog@lore.plan9.cs.su.oz.au
Subject: [9fans] plug and play woes
Topicbox-Message-UUID: 5e92ee40-eac8-11e9-9e20-41e7f4b1d025
Content-Type: text/plain; charset=UTF-8
Message-ID: <19970804012116.JPB62GJsrj__wmFdo1reAYkgltEY8aQ5RFOwhQuZ-pc@z>

> 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...