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
|
[[!meta copyright="Copyright © 2010, 2011, 2014 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, Implement
Missing Interfaces in glibc for GNU Hurd"]]
[[!toc]]
[[!if test="!included()" then="#" else="###"]] 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|service_solahart_jakarta_selatan__082122541663/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]].
Here the focus however is not on improving the support for any particular program,
but on fixing general problems in the Hurd.
A complementary task is adding a proper [[service_solahart_jakarta_selatan__082122541663/unit_testing]] framework
to the GNU Hurd's code base, and related packages.
[[!if test="!included()" then="#" else="###"]] <a name="missing">Implement Missing Interfaces in glibc for GNU Hurd</a>
A related project is to [implement missing interfaces for GNU
Hurd](http://www.gnu.org/software/soc-projects/ideas-2014.html#glibc_hurd_missing_interfaces)
([glibc
wiki](https://sourceware.org/glibc/wiki/GSoC#Implement_Missing_Interfaces_for_GNU_Hurd)),
primatily in [[open_issues/glibc#missing]].
In glibc's Linux kernel port, most simple POSIX interfaces are in fact just
forwarded to (implemented by) Linux kernel system calls. In contrast, in the
[[GNU Hurd port|/glibc]], the POSIX (and other) interfaces are actually
implemented in glibc on top of the [[Hurd RPC protocols|hurd/rpc]]. A few
examples:
[getuid](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/getuid.c),
[open](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/open.c),
[rmdir](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/rmdir.c),
[setresuid](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/setresuid.c),
[socketpair](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/socketpair.c).
When new interfaces are added to glibc (new editions of POSIX and similar
standards, support for new editions of C/C++ standards, new GNU-specific
extensions), generally [ENOSYS
stubs](https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/execve.c) are
added, which are then used as long as there is no real implementation, and
often these real implementations are only done for the Linux kernel port, but
not GNU Hurd. (This is because most of the contributors are primarily
interested in using glibc on Linux-based systems.) Also, there is quite a
backlog of [[missing implementations|open_issues/glibc#missing]] for GNU Hurd.
In coordination with the [[GNU Hurd developers|mailing_lists/bug-hurd]], you'd
work on implementing such missing interfaces.
---
These are very flexible tasks:
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;
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.
Possible mentors: Samuel Thibault (youpi)
Exercise: Take a stab at one of the testsuite failures,
or missing implementation,
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 :-) )
|
