[Top][All Lists]

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

Re: Google Summer of Code 2007

From: Thomas Schwinge
Subject: Re: Google Summer of Code 2007
Date: Tue, 13 Mar 2007 23:23:33 +0100
User-agent: Mutt/1.5.11


On Tue, Mar 13, 2007 at 09:18:32PM +0100, olafBuddenhagen@gmx.net wrote:
> On Mon, Mar 12, 2007 at 12:27:09AM +0100, Thomas Schwinge wrote:
> > http://savannah.gnu.org/task/?5469 -- Rewrite pfinet
> > 
> > The libchannel project should be done before, or at least in parallel,
> > I'd say.
> [...]
> > http://savannah.gnu.org/task/?5485 -- Design and implement a sound
> > system
> > 
> > Both libchannel and the device driver update should be done before, or
> > at least in parallel, I'd say.
> LIbchannel isn't really necessary for either of these projects. Aside
> from the fact that I still don't see any use in a generic libchannel at
> all, there is nothing wrong with implementing these things
> independently, and later moving them to libchannel if someone really
> feels like implementing it. Libchannel is only an optimization.
> Answering any attempt of implementing sound or improved networking or
> whatever with "write libchannel first" doesn't make any sense.

It seemed right to me that all these stream based services should make
use of a to-be-designed-and-written libchannel.  If that doesn't seem
feasible to you, then please elaborate.

As for ``implementing these things'' -- _I__ would rather prefer to use
(via another layer of glue code) existing code for that, because I think
that maintaining a (e.g.) functional TCP/IP stack (IPv4 and IPv6) seems
to be a rather adventurous venture to me.

> Sound support doesn't really depend on a new driver framework either. It
> requires sound drivers in Mach of course, but that doesn't mean all the
> other drivers need to be updated for that.

Well, but you'll definitely want some upgrades of the basics, like bus
access (pci, etc.) and other framework issues.  And then, you have the
possibility to either adapt the old glue code to that new framework or
provide a glue-in-the-glue code to map the new glue code's functions to
what to old glue code expects...

> Another interesting task: Improve subhurds. (Allow running as root, more
> debug possibilities, sharing of services etc.)

``Allow running as _non_-root'', I guess.  Sure, that'd be a very nice
thing, but again doesn't seem really right for a GSoC project to me.  If
you could come up with a self-contained wording for such a task, then I'm
all ears.


Attachment: signature.asc
Description: Digital signature

reply via email to

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