[Top][All Lists]

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

Re: [GSoC] GNU/Hurd Sound Support

From: Mohammed Gamal
Subject: Re: [GSoC] GNU/Hurd Sound Support
Date: Tue, 1 Apr 2008 15:15:59 +0200

On Tue, Apr 1, 2008 at 1:31 PM, Richard Braun <syn@hurdfr.org> wrote:
> On Tue, Apr 01, 2008 at 10:59:09AM +0200, Mohammed Gamal wrote:
>  > I have good experience with C/C++ and I am familiar with POSIX API, my
>  > coding experience was generally in userspace, I didn't do anything
>  > serious in kernel space. As for your suggestion, I think it's a very
>  > good idea.
>  Sound support in the Hurd and Mach requires a lot more knowledge than
>  that. If you want to support old ISA boards, you need to take care of
>  the dirty details about the DMA. If you want to support more recent
>  PCI boards, you need to improve the Mach PCI "subsystem" a lot. You
>  also have to learn the Mach VM and IPC interfaces in depth to use them
>  correctly, and maybe extend them since they may not fit well for what
>  you intend to do (user space drivers). For example, you have no
>  control of the caching policy (you would probably need write-through
>  when mapping PCI boards memory in your user space driver process space).
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?

>  > Sorry, there was some misunderstanding of the term "translator" on my
>  > part here. What I mean is that we'd need a program, rather than a
>  > translator,  for each sound card that'd talk "libsound" that'd in turn
>  > pass messages to the Mach kernel. However, does what you say here mean
>  > that we'd rather have to write the drivers directly in the Mach
>  > kernel?
>  It is currently the most reasonable approach. Most drivers are written
>  for kernels, and unless you intend to rewrite them all, we need to grab
>  existing drivers and plug them into Mach. In addition, Mach has some
>  roots from BSD, and BSD has kept some interfaces from Mach (e.g. the
>  NetBSD UVM system interface is very close to the Mach VM interface).
>  This should reduce the amount of work needed to port BSD drivers.
>  A kernel/userspace event facility was started at some point in time,
>  but it remained experimental and was never actually used to implement
>  any quality driver in userspace. Developing this is completely outside
>  the scope of the GCoS project.
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 above require - for the long term - a new glue layer to be
implemented first?

>  > >  In fact, Richard Braun (syn on IRC) has once tried porting the driver,
>  > >  and had it mostly working, but there was a serious bug he couldn't track
>  > >  down, so he gave up. You could try to contact him -- perhaps you could
>  > >  use his code as a starting point, or at least get some advice.
>  With more experience, I'd suggest you don't use my code. The "bug" I had
>  was mainly due to my misuse of the Mach VM and IPC interfaces, and I
>  currently don't have enough time for hacking on this again :'(. You can
>  find it at http://cvs.sceen.net/index.cgi/gnumach/ though.

>  --
>  Richard Braun
>  Version: GnuPG v1.4.1 (GNU/Linux)
>  iD8DBQFH8h0ZBlWsEPLYRi8RAh5pAJ9pDKXxbhe3Xg6OJx4Y9XT+EJ2ZfgCbBXt2
>  sLTxM3/rBYfDP62SsOdNxv4=
>  =DnBf
>  -----END PGP SIGNATURE-----

reply via email to

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