[Top][All Lists]

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

Re: Personal Introduction

From: Brent W. Baccala
Subject: Re: Personal Introduction
Date: Thu, 5 Apr 2018 18:42:24 -0400

On Thu, Apr 5, 2018 at 11:20 AM, Charlie Sale <softwaresale01@gmail.com> wrote:
Hey Brent

I would be willing to help with that project. I'll see what I can do to contribute. 

You said that you had some code written. Where can I find it? Is it in a branch on the main tree?

No, unfortunately.  Part of the reason is how we interact with Debian.  I run a Debian/Hurd system, and there are Debian-specific patches that haven't been incorporated into our main source tree.  Also, when you get a Debian source tree, it doesn't come with any git version control information.  If I worked on our git tree, then I'd have to figure how to apply the Debian patches to get something that actually runs right.  So, I tend to work on the Debian-ized source tree, without any version control per se.  It's not ideal.

I'm attaching a patch with the work I've done so far on the tracing facility.  It doesn't really do anything, yet, just adds a new system port to each task, and a first crack at a subroutine to create trace messages, but if you read the design message I sent to the list, you'll see that the subroutine isn't as sophisticated as I'm now thinking it needs to be.

Also, I should mention that a major issue on the mailing list for the last two months has been upstreaming glibc.  It's again related to how we interact with Debian.  There are so many Hurd-specific, Debian-specific changes to glibc, that the Debian maintainers have threatened to drop us completely unless we get our code upstreamed into the main glibc code base.  I'm not working on that code, because the Free Software Foundation wants me to sign a copyright assignment whose language I object to, but if you're willing to sign the copyright assignment, I'm sure Samuel Thibault would appreciate some help with that.  It's a bit of a mess, while the project that I'm proposing is more self-contained, but you should know that there's at least one other ongoing project we could use help with.

I'm hoping the copyright assignment won't be an issue with the kernel proper, since it's based on Mach and isn't owned by the FSF, but I'm not 100% of that.

Also, I gave a lecture on Hurd a few months ago that might interest you.  It's an hour and half, and the first part talks about generic HPC issues, but the second part goes into some detail about how Hurd is designed, and my own vision for what I'm trying to do with it.  I've got a screencast on youtube, if you're interested:


Also, would you recommend developing in a GNU/Hurd environment as opposed to a GNU/Linux environment? I tried running Debian GNU/Hurd in qemu, but I had some major troubles with that (keyboard didn't work at all). Should I request an account on the main Hurd machine?

I agree with Samuel that qemu is the way to go.  I use Hurd exclusively in qemu, with Linux running on my bare metal.  Don't try to run Hurd bare metal.  We're not likely to have device drivers to support all of your hardware, plus if you're going to do kernel work, you really want to have it in a virtual machine so you can run gdb on the kernel.

We think your keyboard should work!  Once you get it up and running, though, I don't use its console for day-to-day work.  I ssh into it.

I am excited to try to help!


Attachment: gnumach-trace-port.patch
Description: Text Data

reply via email to

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