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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
[[meta copyright="Copyright © 2009 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]]."]]"""]]
## libpciaccess Support for GNU Hurd
xserver 1.5 introduces libpciaccess as a new method for handling PCI devices.
The purpose was to get rid of the messy old PCI code in the server, instead
using a new implementation that is encapsulated in a library, and uses external
PCI access interfaces provided by the operating systems.
As libpciaccess is written from scratch, support for various operating systems
needs to be reimplemented individually, writing specific backends for each.
This task is about creating such a backend for GNU Hurd.
Writing a "proper" native backend for the Hurd is rather involved, as there is
no kernel PCI interface so far -- it has to be created first. It would also
have the disadvantage of being somewhat tied to the specific driver framework:
The present framework is pretty dated (using some ancient Linux drivers with a
layer of glue code); and when this is replaced, the PCI interface will have to
be updated as well.
Alternatively, a libpciaccess backend simply doing old-style register poking
from user space could be implemented. (Either from scratch, or by reusing some
existing PCI code from the old server or some BSD kernel.) That approach is not
as elegant; it would be somewhat fragile and limited, like the old PCI code in
the server. On the other hand, it is much simpler to implement; and it would
also benefit other non-mainstream platforms that can't afford
creating/maintaining a native backend.
The goal of this project is getting a recent xorg server, using libpciaccess,
to run on the Hurd.
This task probably doesn't require any previous X programming knowledge, though
a bit of experience with PCI programming will probably help. Some Hurd-specific
knowledge will have to be obtained while working on it -- especially if
implementing a proper kernel PCI interface. The task is pretty involved in the
latter case, but shouldn't be too hard if taking the user space register poking
approach.
Exercise: Implement a stub backend for libpciaccess, which doesn't really do
anything useful, but compiles fine on the Hurd.
## VT Switching for GNU Hurd
While XFree86 was first ported to the Hurd more than a decade ago, and there
are updates now and then to make newer versions of Xorg run as well (see also
the libpciaccess task), the support is quite rudimentary: in particular, there
is no support for switching back to the text console while X is running.
Implementing this requires creating an interface between the X server and the
Hurd console, and implementing the necessary code on both sides.
The goal of this project is to get console switching fully working on the Hurd.
Some Hurd-specific and X-specific knowlegde will need to be obtained, but the
task should be quite doable without previous experience with either. It
requires implementing some pieces of code that are not quite trivial, but
shouldn't be terribly hard either.
Exercise: Try fixing <http://savannah.gnu.org/bugs/?21000>, or perhaps some
other minor issue with X on the Hurd.
## Initial work on porting DRM to GNU Hurd
The Direct Rendering Manager (DRM) is a kernel driver component taking care of
graphics hardware access. Originally, it only took care of the 3D acceleration
unit, and was used mostly by the DRI (Direct Rendering Infrastructure) in Mesa.
About two years ago, the developers came to the conclusion that a more robust
and functional graphics stack requires the kernel driver to take care of other
graphics access as well: mode setting in particular. (Essentially what the old
KGI project proposed, see <http://www.kgi-project.org>.) Also, with the new GEM
interface, the DRM now takes care of graphics memory management as well.
With the new responsibilities, the DRM is no longer an optional addon for fast
3D support, but a central component of the graphics stack. It needs to be
implemented by any operating system that wants good Xorg driver support in the
future. (Moreover, it is now also useful outside the context of Xorg.)
The Hurd implementation of DRM will be somewhat special, as -- following the
microkernel idea -- we want to run the drivers as priviledged user space server
processes, rather than actual kernel modules.
This task is about doing the first steps for porting the DRM to the Hurd. This
can be done by taking one of the existing DRM modesetting drivers (Intel or
Radeon), trying to get parts of it running as a Hurd server, and
porting/implementing necessary pieces of the general DRM framework as needed
along the way.
It is probably not realistic to get the driver fully working over the summer.
The goal however is to get at least some parts going.
This task will require obtaining a considerable amount of knowledge about the
Hurd and Mach (especially things like virtual memory management) -- it goes
deep into system internals. Previous experience with operating system and/or
graphics driver development would definitely be helpful.
Exercise: Try to get some part of the driver compiling on the Hurd, using stubs
for any system-specific functionality.
|
