1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled
[[GNU Free Documentation License|/fdl]]."]]"""]]
[[!meta title="New Driver Glue Code"]]
Although a driver framework in userspace would be desirable, presently the Hurd
uses kernel drivers in the microkernel,
[[GNU_Mach|microkernel/mach/gnumach]]. (And changing this would be far beyond a
GSoC project...)
The problem is that the drivers in GNU Mach are presently old Linux drivers
(mostly from 2.0.x) accessed through a glue code layer. This is not an ideal
solution, but works quite OK, except that the drivers are very old. The goal of
this project is to redo the glue code, so we can use drivers from current Linux
versions, or from one of the free BSD variants.
While it would be certainly possible to create custom glue code again, a more
sustainable and probably also easier approch is to use
[[DDE]] instead -- it already
does the hard work of providing an environment where the foreign drivers can
run, and has the additional advantage of being externally maintained.
This is a doable, but pretty involved project. Previous experience with driver
programming probably is a must. (No Hurd-specific knowledge is required,
though.)
This is [[!GNU_Savannah_task 5488]].
[[open issues/user-space device drivers]].
[[open issues/device drivers and io systems]].
Possible mentors: Samuel Thibault (youpi)
Exercise: Take a driver for some newer piece of hardware (e.g. Intel e1000
ethernet) from a recent system, and try to port it to run in the existing
driver framework in GNU Mach. Completing the port might be too involved for the
exercise; but it's pretty likely that you will find something else to improve
in the glue code while working on this...
|
