Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I am working on some more bits of my device manager and have a few queries regarding methodology.
1. For standard devices, such as the PIT, RTC etc... I have assumed that they exist as part of the PC specification and have not attempted to implement any device detection. Does that seem reasonable?
2. How about for the COM ports? All the sample drivers I have seen don't seem to bother with detection, but I suppose there must be some way to do it - via CMOS?
3. My Bus Drivers ( ) at present are responsible for (a) detecting the Bus they are responsible for and (b) detecting and loading drivers attached to the bus. Again, does this seem reasonable, or is it more usual for the kernel to load the bus driver, then load the individual device drivers itself?
1 - most of the 'standard' components are undetectable, and you must assume they are present
2 - same as above -- the COM ports (and LPT ports) arnt actual devices, they are address ranges -- they are always present on all computers even if the computer has no physical ports -- not all devices on the COM ports are connected to the connector -- most dial-up modems are connected through the COM ports but they are internal to the computer and on the ISA or PCI bus, but they are considered to be on the COM ports because they respond to those addresses and use those interupts
what you must do is look to see if anything is connected to them (if nothing is connected, the port still exists)
3 - ifaik this is the normal way to do it (it sounds quite logical to me anyway)
The PIC and RTC can't just evaporate from the motherboard upon the whim of some PC manufacturer. Operating systems like Windows have got to be able to make some assumptions about the hardware they are running on.
I suppose a commercial OS developer might make it part of his minimum system specification that the computer was 100% PC compatible.
The usual way to detect the presence of a chip is to write to one of the i/o ports, and then see if you can read back what you wrote. Of course you have to be careful that whatever you write does not have undesirable results. Some chips, such as the keyboard controller, can be persuaded to generate signature byte(s).
AJ wrote:2. How about for the COM ports? All the sample drivers I have seen don't seem to bother with detection, but I suppose there must be some way to do it - via CMOS?
It's possible to manually probe for serial ports. Start with a list of possible base I/O ports and remove anything that conflicts with any hardware you already know about. Then, for each potential serial port try to enable loopback mode and see if data you send is received (and if the relevant status flags behave). For a quick example, see this code.
Once this is done and you're sure there is a serial port there, you can enable interrupts, make the serial port generate an IRQ and auto-detect which IRQ it's connected to.
Detecting which devices (if any) are connected to the serial port is another matter, but also possible in some cases (typically serial mouse or modems can be autodetected). Google for "Plug and Play External COM Device Specification" for details (the PDF contains information for serial devices that do support PnP, and some information that's useful for detecting serial devices that don't support PnP)...
Cheers
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
) at present are responsible for (a) detecting the Bus they are responsible for and (b) detecting and loading drivers attached to the bus. Again, does this seem reasonable, or is it more usual for the kernel to load the bus driver, then load the individual device drivers itself?
