Hello, all...
I'm actually entering the firghtful step of starting IO subsystem for Clicker. I've now got a working "resource allocator" that will allow modules to request resource like memory regions or ports range and avoiding two module allocate the same resource.
I will then try to add IO devices and drivers. So far, the way i think i'll handle this will be through a bus-driver module that will enumerate existing devices and then load the appropriate device drivers.
I also plan to replace the infamous "IOCTL" function by a service that you can also enumerate (so that you can learn at run time what kind of API are available on system.io.device.eth0, for instance)
Do you have some hints/suggestion to make? How would you list block devices, for instance (partitions, removable media, etc ...)
Should there be a single "system.dev.floppy" or one instance per "media" that has been made present (MACintosh-like) ? ...
designing the IO subsystem.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
-
DarylD
Re:designing the IO subsystem.
I think Tim has an I/O system though, don't you?All I can say Pype, being in the position of trying to code my own IO sysem (although not on the same scale as yours probably) is its a lot of fun!
My biggest problem was ensuring performance was suitable, I am still unhappy that I will get some BIG bottlenecks due to the design.
I think Tim has an I/O system though, don't you? Although I think Tim's is IOCTL based.
Daryl.
My biggest problem was ensuring performance was suitable, I am still unhappy that I will get some BIG bottlenecks due to the design.
I think Tim has an I/O system though, don't you? Although I think Tim's is IOCTL based.
Daryl.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:designing the IO subsystem.
I've been thru Tim's device driver documentation as well as thru some of Micro$oft Driver Development Kit (DDK) -- which surprised me alot : i didn't expect the BIG-MS to give that much design info for free 
As the win-DDK seems more clear to me than Linux DDK, i think i will inspirate from the former one. Here are how i plan things so far:
ioBusDriver : will be instanciated by the Root Driver for every system bus the architecture recognizes. It will scan for hardware device on that bus and create ioDeviceInfo for each of them.
The ioDeviceInfo will encapsulate any information a device driver would like to know to talk to the device (like is the drive on primary/secondary IDE ? is it slave or master ? where is the root sector ? etc.) as well as device abillities (can it do UltraDMA, etc.)
ioDriverBroker will get the device identification (made of <ioDeviceInfo.bus()> <ioDeviceInfo.deviceId()> <ioDeviceInfo.abilities()>) and lookup the driver database for a matching driver. This means the ioDriverInfo have registered to the ioDriverBroker formerly with their module and supported deviceId() and abilities() ...
ioDriver are loaded out of modules by the broker and we will call ioDriver.init(ioDeviceInfo) to get a ioDevice instance. That ioDevice will have some interface-based (? la COM) services to access them. So far i can envision 3 main interface: "iBlock {read, write}", "iChar {put, get}" and "iControl {enumerate, getCtlInterface}".
once you get the interface on the ioDriver, you're ready to do read/write requests.
sounds fine ?
As the win-DDK seems more clear to me than Linux DDK, i think i will inspirate from the former one. Here are how i plan things so far:
ioBusDriver : will be instanciated by the Root Driver for every system bus the architecture recognizes. It will scan for hardware device on that bus and create ioDeviceInfo for each of them.
The ioDeviceInfo will encapsulate any information a device driver would like to know to talk to the device (like is the drive on primary/secondary IDE ? is it slave or master ? where is the root sector ? etc.) as well as device abillities (can it do UltraDMA, etc.)
ioDriverBroker will get the device identification (made of <ioDeviceInfo.bus()> <ioDeviceInfo.deviceId()> <ioDeviceInfo.abilities()>) and lookup the driver database for a matching driver. This means the ioDriverInfo have registered to the ioDriverBroker formerly with their module and supported deviceId() and abilities() ...
ioDriver are loaded out of modules by the broker and we will call ioDriver.init(ioDeviceInfo) to get a ioDevice instance. That ioDevice will have some interface-based (? la COM) services to access them. So far i can envision 3 main interface: "iBlock {read, write}", "iChar {put, get}" and "iControl {enumerate, getCtlInterface}".
once you get the interface on the ioDriver, you're ready to do read/write requests.
sounds fine ?