| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
Initial note: if anyone has access to Micro$oft's Device Developer Kit, please send me the detailed description of the .inf files used in device configuration. If we could use these in JOS, it would be a huge amount of hardware testing already complete.
The current code and description has gone under the knife. This project has grown exponentially in scope, and now covers the Platform interfaces (which is almost done coding, pending some changes under discusion in the kernel mailing list), the JOS ConfigurationDatabase, Jini Look-up services, Device and Bus Driver base design, and the ConfigurationManager. The current design is listed under DeviceArchitecture.
Other related references:
-MattAlbrecht 30-MAR-1999
To properly develop a hardware device detection system, a basic platform architecture needs to first be created. Since no one has yet come up with an agreed upon architecture, I'll propose a simple one based on IBM/Sun's JavaOS (hopefully, loosely so no lawsuits can ensue). The base example driver I'll use is the VGA video driver for the PC.
The platform package contains Java versions of generally native calls to base I/O operations needed for device drivers:
Along with maintaining an interface to said hardware, it should also keep track of who has allocated these resources, and should prevent multiple drivers from allocating the same resources.
There may be multiple busses per platform. Each bus is in charge of:
This class is in charge of managing the various bus classes which populate the hardware.
It is, in the general JOS implementation, an abstract class. This is because of the extremely hardware-dependant interfaces which can occur. However, certain "helper methods" should be added to make the basic management much easier.
(This is heavily influenced by JavaOS - have any better ideas? Then post them!)
The driver repository has an RMI-esque interface to keep a network-wide access open for known devices on the network.
After a device has been discovered and has been assigned to the proper allocated and initialized hardware resources, it is passed to the driver repository. It is the repository's duty to find a driver and associate it with the machine/device passed to it, then to initialize the driver.
As an example of how convoluted this can be, let's look at the PC with all of its variations.
Initially, we must check for any LegacyISA (International Standard Architecture) cards. These are very difficult to find, since there is no systematic approach to discovery - we must have a set of "finder" functions which tell us how to discover as many cards as possible. Or, we could require the user to tell us which is in the system, then attempt to check if the given information is true. Since this can be an indepth and time consuming process, a record of the current configuration should be maintained (a la Win'95's CMOS registry, but without the CMOS storage). This would require the user to inform the OS when a card has been added (removal is more easily detected).
Assuming that we found all of these Legacy ISA cards, we then move on to EISA (Extended ISA) cards. These are easier to detect as they support PlugAndPlay architecture. Also, every EISA card is assigned a slot number, and can be accessed individually through different port ranges per slot.
It is then the bus manager's responsibility to integrate the ISA and EISA device lists - if an ISA card is also in the EISA list, then remove it from the ISA list. We must search ISA initially to prevent possible PlugAndPlay screwups (notice Win'95 PnP support).
Then we can search for PCI cards. They fully support PlugAndPlay, so we follow the same procedure as for EISA.
If we find that there exists on this PC a PCMCIA bus, then the Platform MUST support sharable interrupts (i.e. interrupt chaining). To be fully PCMCIA compliant, it must also support 32-bit PCMCIA device drivers. We must also set up a Socket and Card Service interfaces for these drivers to interact with.
Even then, with all cards discovered, we must pass all the hardware requirements on to the Bus Manager (or someone else who is qualified) to sort out who gets which resources (with PnP, the configuration is commonly configurable, with an optimized configuration).
I believe that the above architecture can fully cover the needs of any architecture, but only if most classes are left abstract, to be filled in by each platform's needs.
-MattAlbrecht 25-AUG-1998
Updated 27-AUG-1998
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|