Hello! On Tue, Mar 13, 2007 at 09:18:32PM +0100, [EMAIL PROTECTED] 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. Regards, Thomas
signature.asc
Description: Digital signature
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
