Differences

This shows you the differences between two versions of the page.

--- genericinputdevicelayer [2007/04/17 12:44] – MaximZhuravlev
+++ genericinputdevicelayer [2018/03/18 17:38] (current) – fix broken link; historical page. MarkLinimon
@@ Line 1: / Line 1: @@
 ===== Generic Input Device Layer =====
-[http://wiki.freebsd.org/SummerOfCode2007 %%GSoC%% 2007] Project
+[[SummerOfCode2007|GSoC 2007]] Project
-Student: [http://wiki.freebsd.org/MaximZhuravlev Maxim Zhuravlev]
+Student: MaximZhuravlev
-Mentor: [http://wiki.freebsd.org/PhilipPaeps Philip Paeps]
+Mentor: PhilipPaeps
-Original proposal: [http://amd.streamload.com/thioretic/Hosted/GIDL.pdf here]
+Original proposal: [[http://amd.streamload.com/thioretic/Hosted/GIDL.pdf|here]]
 ==== Status ====
+Up-to-date info here: [[EnhancedNewBus|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 ===
+[[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 | 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:
+[[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** driver**s** ||
+| functional | **functional** driver & **filter** driver**s** ||
+== 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
 === April 14 ===
 Study the following links (and code of course) for design patterns:
-  * [[[http://wiki.freebsd.org/dev/vtc(4]]) [[http://wiki.freebsd.org/dev/vtc%284%29]]] %%//%% hmmm... code seems to do nothing as to keyboard and mouse handling. Or have I missed something?
+  * [[dev/vtc(4)]] %%//%% hmmm... code seems to do nothing as to keyboard and mouse handling. Or have I missed something?
   * http://www.kgi-project.org
   * http://developer.apple.com/documentation/DeviceDrivers/Conceptual/HID/ (well, actually got xnu code long time ago. Will check it out)
@@ Line 18: / Line 90: @@
 ==== Links ====
-  - [[[http://wiki.freebsd.org/dev/vtc(4]]) dev : vtc(4) Video Terminal and Console]
+  - [[dev/vtc(4)|dev : vtc(4) Video Terminal and Console]]
-  - [http://www.semicomplete.com/projects/newpsm/ Jordan Sissel's newpsm framework]
+  - [[http://www.semicomplete.com/projects/newpsm/|Jordan Sissel's newpsm framework]]
-  - [http://www.freebsd.org/cgi/man.cgi?query=kbdmux&apropos=0&sektion=0&manpath=FreeBSD+6.2-RELEASE&format=html kbdmux(4)]
+  - [[http://www.freebsd.org/cgi/man.cgi?query=kbdmux&apropos=0&sektion=0&manpath=FreeBSD+6.2-RELEASE&format=html|kbdmux(4)]]
-  - [http://www.kgi-project.org KGI Project]
+  - [[http://www.kgi-project.org|KGI Project]]
-  - Linux [http://www.linuxjournal.com/article/6396 'input core']
+  - Linux [[http://www.linuxjournal.com/article/6396|'input core']]
-  - %%MacOS%% [http://developer.apple.com/documentation/DeviceDrivers/Conceptual/HID/ Introduction to Working With HID Class Device Interfaces]
+  - [[http://liquidat.wordpress.com/2007/07/21/linux-kernel-2623-to-have-stable-userspace-driver-api/|Linux kernel 2.6.23 to have stable userspace driver API]]
-  - MS Windows [http://www.microsoft.com/whdc/driver/wdf/UMDF_Intro.mspx Introduction to the WDF User-Mode Driver Framework]
+  - %%MacOS%% [[http://developer.apple.com/documentation/DeviceDrivers/Conceptual/HID/|Introduction to Working With HID Class Device Interfaces]]
+  - MS Windows [[http://www.microsoft.com/whdc/driver/wdf/UMDF_Intro.mspx|Introduction to the WDF User-Mode Driver Framework]]
+----
+{{tag>Historical}}