GenericInputDeviceLayer [FreeBSD WIKI]

This is an old revision of the document!

[http://wiki.freebsd.org/SummerOfCode2007 GSoC 2007] Project

Student: [http://wiki.freebsd.org/MaximZhuravlev Maxim Zhuravlev]

Mentor: [http://wiki.freebsd.org/PhilipPaeps Philip Paeps]

Original proposal: [http://amd.streamload.com/thioretic/Hosted/GIDL.pdf here]

July 27

[http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2007/thioretic%5fgidl&HIDEDEL=NO 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: [http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2007/thioretic%5fgidl2&HIDEDEL=NO 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	not yet started

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: [http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2007/thioretic%5fgidl&HIDEDEL=NO Project PERFORCE branch]

[http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/soc2007/thioretic%5fgidl/TODO 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 [http://docs.FreeBSD.org/cgi/mid.cgi?46250237.000008.20157 '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