bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC] GNU/Hurd Sound Support


From: Richard Braun
Subject: Re: [GSoC] GNU/Hurd Sound Support
Date: Tue, 1 Apr 2008 17:04:41 +0200
User-agent: Mutt/1.5.9i

On Tue, Apr 01, 2008 at 03:15:02PM +0200, Mohammed Gamal wrote:
> I am familiar with the Linux kernel, although on a basic "big picture"
> level, and I am also familiar with its device driver subsystem.
> However the whole point of GSoC is to develop one's skills by getting
> involved in the FOSS community, so I really don't mind learning a lot
> of things, the question is whether it'd be feasible to learn and
> acquire the skills needed for this project in the scope of GSoC?

Honestly, I doubt it. Keep in mind that the project must be in a
working state by the end of August. This means that you must acquire the
knowledge and thinking required to develop in Mach and the Hurd, and
also take some time to write down the detailed design, including the
kernel/userspace interface (we probably won't support anything like
ALSA). Then plug a driver, implement the interface and the translator,
and handle all the gory details. You are very likely to run into hard
to solve kernel bugs (which can take you several days, even weeks to
solve, if you even solve them). You will also have to dig into core
Hurd libraries and GLIBC (you will very probably need to create specific
ioctl handlers and add them to GLIBC, which also requires understanding
some tricky MiG options). All of this can be achieved, but in 3 months,
without much experience with the Hurd, it will be a tough job. Add to
the picture that Mach and the Hurd have bugs (really), which will give
you a hard time validating your own work.

In my opinion, any kernel related work should be avoided in the context
of GSoC, they require more time than is provided to students.

> Wouldn't this require a glue layer in order to use other OSs drivers?
> One GSoC idea was to update the the Linux glue layer for recent
> kernels, so wouldn't adding sound support with the approach you
> mentioned require - for the long term - a new glue layer to be
> implemented first?

Simply put, yes. My own roadmap was about porting Linux 2.2 drivers.
As GNU Mach already provides a Linux 2.0 glue layer, I assumed it
wouldn't require too much code.

-- 
Richard Braun

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]