Generic Input Device Layer

GSoC 2007 Project

Student: Maxim Zhuravlev

Mentor: Philip Paeps

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:

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

DEVICES

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:

Thanks to Nicolas Souchu and Pedro F. Giffuni for provided information.

  1. dev : vtc(4) Video Terminal and Console

  2. Jordan Sissel's newpsm framework

  3. kbdmux(4)

  4. KGI Project

  5. Linux 'input core'

  6. Linux kernel 2.6.23 to have stable userspace driver API

  7. MacOS Introduction to Working With HID Class Device Interfaces

  8. MS Windows Introduction to the WDF User-Mode Driver Framework

GenericInputDeviceLayer (last edited 2008-06-17 21:38:23 by localhost)