Generic Input Device Layer
GSoC 2007 Project
Student: MaximZhuravlev
Mentor: PhilipPaeps
Original proposal: here
Status
Up-to-date info here: Enhanced NewBus Project.
August 9
Input/output handling in enhanced newbus
FAQ
Q. Hey, we have netgraph, geom, usb stack and more, why do we need to implement something else?
A. Historically, to support autoconfiguration a driver should implement *DRIVER_MODULE* (remember bluetooth support). It resulted in that various devices are in newbus tree. Ouch, not newbus tree, but newbus graph. So the newbus is a common hosting place for all those devices. The enhanced newbus is to support functional devices -- upper level entities. As they may need to coordinate different types of devices (geom-, netgraph-driven, etc),we need a common way to pass control between different nodes in newbus tree. This is why we need i/o handling in newbus.
Q. Why do we need to implement all that stacking in the kernel?
A. It's because a functional device may be not a leaf, but a node of the tree. Some, eg. terminal, early-boot driver may be a child of a demuxing device. That's why we need it in kernel.
July 27
soc2007/thioretic_gidl has reached polishing/testing/debugging period. No more features but those, listed in July 17 status update. The period seems to be long enough, taking into account all those changes made, and amount of code, that uses the api.
But development should continue. The features to be implemented: input/output handling, locking. These are next two milestones. This is the branch, where all work on them will be held: soc2007/thioretic_gidl2.
soc2007/thioretic_gidl testing will include:
semantics verification |
in progress |
|
machine should boot successfully |
not yet started |
|
three test drivers (device, filter, functional) should stick into the newbus tree correctly |
not yet started |
|
soc2007/thioretic_gidl2 features to be implemented:
i/o handling |
in progress |
|
locking |
in progress |
|
As a result soc2007/thioretic_gidl will be the most stable one, while soc2007/thioretic_gidl2 will be the most up-to-date.
July 17
Update time. Better late than never. First some useful links, you can use to keep track of my project:
TODO File [Well, it's not a real todo file with capital 'T'. It's mainly a place, where some key ideas are being stored.]
Rationale
One can call the design being implemented an enhanced newbus, to put it mildly :). Really, the old newbus codebase works at the very begining of the enhanced newbus lifecycle. Will start from kind diversity. There are some terminology news:
DRIVERS
- device
- filter
- functional
DEVICES
- 'real'
- functional
Yes, I'll ask my wife to give names to my children. Honestly. Since now, each device is controlled not by a single driver:
device type |
drivers, which handle the device |
|
'real' |
device driver & filter drivers |
|
functional |
functional driver & filter drivers |
|
Who are you, functional devices?
Functional devices are those, not backed by any real device. These are multiplexing, demultiplexing, ... devices. One of the most noticable features of functional devices, is that they may have several parents. In the times of old newbus each device could have multiple children (remember about buses), but not parents.
WELL, BY NOW THERE SEEMS TO BE NO MORE TECHNICAL REASONS FOR ALL THE STUFF NOT TO WORK.'
But, all that is just the beginning of the fairy tail. If you every asked yourself about why do we need all those mysterious device stacks (usb,...), while we have newbus, you would understand, that one of the reasons is ... yes, newbus doesn't handle i/o requests. But, hopefully, since now it will.
April 27
Community 'Intro and Sync' mail turned out to be quite a useful one ;). One of most obvious designs, taking into account the advices, given in the mailing list thread, is to move stacking into kernel. This may be done by extending newbus (still thinking, update soon).
Pluses: fairly generic decision
Minuses: compartibility issues to be bypassed
April 14
Study the following links (and code of course) for design patterns:
dev/vtc(4) // hmmm... code seems to do nothing as to keyboard and mouse handling. Or have I missed something?
http://developer.apple.com/documentation/DeviceDrivers/Conceptual/HID/ (well, actually got xnu code long time ago. Will check it out)
Thanks to Nicolas Souchu and Pedro F. Giffuni for provided information.
Links
Linux 'input core'
MacOS Introduction to Working With HID Class Device Interfaces
MS Windows Introduction to the WDF User-Mode Driver Framework