summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas
diff options
context:
space:
mode:
authorantrik <antrik@users.sf.net>2009-03-22 20:40:30 +0100
committerantrik <antrik@users.sf.net>2009-03-24 05:40:55 +0100
commitc8f179173da09998cb37034ee91b09039582079b (patch)
treead6af2f9c99923d6aba85d477515920df422478e /community/gsoc/project_ideas
parent467257e37d049564f47c7f54d92c1fbf5582b1ae (diff)
New GSoC task: Dummy hardware access libraries
Diffstat (limited to 'community/gsoc/project_ideas')
-rw-r--r--community/gsoc/project_ideas/hardware_libs.mdwn41
1 files changed, 41 insertions, 0 deletions
diff --git a/community/gsoc/project_ideas/hardware_libs.mdwn b/community/gsoc/project_ideas/hardware_libs.mdwn
new file mode 100644
index 00000000..e3680378
--- /dev/null
+++ b/community/gsoc/project_ideas/hardware_libs.mdwn
@@ -0,0 +1,41 @@
+[[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]]."]]"""]]
+
+[[meta title="Stub Implementations of Hardware Specific Libraries"]]
+
+Many programs use special libraries to access certain hardware devices, like
+libusb, libbluetooth, libraw1394 etc.
+
+The Hurd presently doesn't support these devices. Nevertheless, all of these
+programs could still be built -- and most of them would indeed be useful --
+without actual support of these hardware devices. However, as the libraries are
+presently not available for Hurd, the programs can't be easily built in Debian
+GNU/Hurd due to missing dependencies.
+
+This could be avoided by providing dummy libraries, which the programs could
+link against, but which wouldn't actually do any hardware access: instead, they
+would simply return appropriate error codes, reporting that no devices were
+found.
+
+There are two possible approaches for providing such stub libraries: Either
+implement replacement libraries providing the same API as the real ones; or
+implement dummy backends for the Hurd in the proper libraries. Which approach
+to prefer probably depends on the structure of the various libraries.
+
+The goal of this project is to create working dummy libraries/backends for the
+mentioned devices, and get them into Debian GNU/Hurd. It shouldn't require any
+special previous knowledge, though some experience with build systems would be
+helpful. Finishing this task will probably require learning a bit about the
+hardware devices in question, and about Debian packaging.
+
+Possible mentors:
+
+Exercise: Get one of the libraries to compile on Debian GNU/Hurd. It doesn't
+need to report reasonable error codes yet -- just make it build at all for now.