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
|
[[!meta copyright="Copyright © 2010, 2011 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="Fix Compatibility Problems Exposed by Testsuites"]]
A number of software packages come with extensive testsuites.
Some notable ones are [[open_issues/glibc]], gnulib, Perl,
Python, GNU Coreutils, and glib.
While these testsuites were written mostly to track regressions in the respective packages,
some of the tests fail on the Hurd in general.
There is also the [[Open POSIX Testsuite|open_issues/open_posix_test_suite]]
which is more of a whole system interface testing suite.
Then, there is the [[open_issues/File_System_Exerciser]] which we can use to
test our file system servers for conformity.
While in some cases these might point to wrong usage of system interfaces,
most of the time such failures are actually caused by shortcomings in Hurd's implementation of these interfaces.
These shortcomings are often not obvious in normal use,
but can be directly or indirectly responsible for all kinds of failures.
The testsuites help in isolating such problems,
so they can be tracked down and fixed.
This task thus consists in running some of the mentioned testsuites
(and/or any other ones that come to mind),
and looking into the causes of failures.
The goal is to analyze all failures in one or more of the listed testsuites,
to find out what shortcomings in the Hurd implementation cause them (if any),
and to fix at least some of these shortcomings.
Note that this task somewhat overlaps with the [[Perl/Python task|perl_python]] listed above.
Here the focus however is not on improving the support for any particular program,
but on fixing general problems in the Hurd.
This is a very flexible task:
while less experienced students should be able to tackle at least a few of the easier problems,
other issues will be challenging even for experienced hackers.
No specific previous knowledge is required for this task;
only fairly decent C programming skills.
While tracking down the various issues,
the student will be digging into the inner workings of the Hurd,
and thus gradually gaining the knowledge required for Hurd development in general.
A complementary task is adding a proper [[open_issues/unit_testing]] framework
to the GNU Hurd's code base, and related packages.
Possible mentors: Samuel Thibault (youpi)
Exercise: Take a stab at one of the testsuite failures,
and write a minimal testcase exposing the underlying problem.
Actually fixing it would be a bonus of course --
but as it's hard to predict which issues will be easy and which will be tricky,
we will already be satisfied if the student makes a good effort.
(We hope to see some discussion of the problems in this case though :-) )
|
