Pardon the naivety and ignorance of my question, but - given the modular architectural nature of the hurd, how difficult would it _really_ be to implement a hurd daemon (terminology?) that would abstract away the underlying differences between the linux kernel and the hurd, such that this type of maintainence would be unnecessary or minimal at worst? Is this not an option for these types of tools, i.e. this is assembly-level type stuff? Is there already some sort of binary-compatibilty layer/daemon for the toolchain or any other linux binary executable? Ideally, there would be nigh-transparent portability and compatibility between linux and the hurd. Presumably, it'd theoretically be more efficient to adapt and maintain one thing, rather than several or dozens of things.
Again, forgive me if this question was totally off-base, or if this idea has already been hashed out and shot down. I'm good with C, but know substantially less than you all do about kernel development or the innards of the gnu toolchain. I'd be interested in trying to help out with the hurd, but i don't know if i'd have enough time to get up to speed to the point where i could contribute anything useful. I like the idea and design of the hurd, but from my perspective, the learning curve looks pretty steep here. ----- Original Message ---- From: Thomas Schwinge <[EMAIL PROTECTED]> To: [EMAIL PROTECTED]; bug-hurd@gnu.org Sent: Wednesday, November 15, 2006 1:08:06 PM Subject: Maintaining the tool chain Hello! I just added an item to ``The GNU Hurd - People at Savannah: Project Help Wanted'', <http://savannah.gnu.org/people/?group=hurd>: #v+ ``Maintaining the tool chain'' We seek help in keeping the Hurd-specific parts of the GNU tool chain (mostly GCC, binutils and glibc) up-to-date in an environment where the tool chain is being advanced for the Linux kernel, as an example, and subsequently the Hurd-specific parts would need to be adopted to these advancements. Please contact us mailing to <bug-hurd@gnu.org> if you are interested in helping here. #v- Thanks to Michael Banck for the suggestion to add such a inquiry. Regards, Thomas _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
