No, they are technically shareable, as long as you don't attept to
expect either of them at the software level to respond at a certain
time. This is why you can have COM2 and COM4 on the same interrupt in
windows or DOS, as long as you don't use them at the same time. The ISA
bus is a very simple interface, and typically nothing at the hardware
level causes a system to crash when resources are shared. It is usually
a driver expecting information from its device, when another one is
already using a certain interrupt. The only counter to this is MIO
and PIO, where the result of an input is undefined, and an output is
supposed to cause the data to go to both devices. I was actually aiming
more towards, memory allocations, and other things like MTRRs and X
and stuff. From the MTRR standpoint, most 6th gen processors (for the
sake of argument the K6CXT is 6th gen) have MTRRs, registers that can
define how memory ranges are utilized in the processor. There are only a
finite number of these, therefore if you were to disable them for some
hardware that didn't need them you could spread them out. It would also
be really great (and I was originally not informed about the current
state of autoloading/unloading of modules for fs and net devices) to
move completely to loading everything out of klds, rather than compiling
the kernel. It may also help some debugging to be able to pull apart
the kernel peice by peice, having a basic default "failsafe" kernel to
boot from that would subsequently begin to load the necessary modules
specified, or to load them in real time and unload them when finished.
I really am not sure about the reality of this proposal, and someone
brought it up earlier, so I thought I'd stick my head in on it. This
email is getting rather lengthy, maybe I'll try fiddling with something
tonight... school is over until summer quarter starts.

Mike Smith had the audacity to say:
> 
> They're "non shareable" at the hardware level ... like all the "non 
> shareable" hardware resources.
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu

PGP signature

Reply via email to