Re: Hurd lecture

On Fri, Jan 19, 2018 at 4:47 AM, Thomas Schwinge wrote: > > Could we add that to the collection of presentations that we've got on > the > > documentation page? > > If you'd like to, you can add it yourself using the wiki interface at > , or ev

Re: Hurd lecture

On Fri, Jan 19, 2018 at 7:35 AM, Ricardo Wurmus wrote: > > Hi Brent, > > > I put a screencast of the lecture on youtube: > > > > https://www.youtube.com/watch?v=JwsuAEF2FYE > > thank you. This was very interesting. The introduction to Mach IPC and > memory management was especially good. I won

libpager, proc server, rpctrace, and other meandering

Hi - I'm writing to update the list on my current work and possibly get some useful suggestions. I'm trying to test the multi-client libpager in a subhurd, but I'm having problems even getting the old libpager code to work cleanly in a subhurd, so I know I've got problems that aren't just in my c

glibc / proc server interaction

Hi - I'm having trouble understanding how glibc's fork() interacts with the proc server. In fork.c, we call task_create (line 172 in the Debian code), then shortly thereafter we call the proc server's proc_task2proc (line 205), and no error returns are tolerated. How do we know that the proc ser

Re: glibc / proc server interaction

On Mon, Feb 5, 2018 at 1:51 AM, Samuel Thibault wrote: > Hello, > > Brent W. Baccala, on lun. 05 févr. 2018 00:35:17 -0500, wrote: > > How do we know that the proc server knows about the task yet? It will > get a > > notification from the kernel that a new task has been

Re: glibc / proc server interaction

On Mon, Feb 5, 2018 at 2:42 PM, Brent W. Baccala wrote: > On Mon, Feb 5, 2018 at 1:51 AM, Samuel Thibault > wrote: > >> Hello, >> >> Brent W. Baccala, on lun. 05 févr. 2018 00:35:17 -0500, wrote: >> > How do we know that the proc server knows a

attaching rpctrace to running processes

Hi - I've modified rpctrace to attach to running processes and trace them. I've added a new set of patches (the 0200 series) to my github repository with these changes. I'm still chasing bugs, and it can't detach from processes without killing them, but it's basically working. The only big prob

gnumach debugger advice

Hi - Can anybody advice me how to use the gnumach debugger for a particular case? I've got a subhurd's proc server that is blocked in the kernel RPC processor_set_tasks(). That thread is holding a global lock in the proc server and locking up the program while waiting for the RPC to return, whic

Re: gnumach debugger advice

On Sun, Feb 11, 2018 at 4:42 AM, Samuel Thibault wrote: > Brent W. Baccala, on dim. 11 févr. 2018 01:23:10 -0500, wrote: > > So how can I figure out where in processor_set_tasks() (or its > subroutines) > > that the kernel has blocked? > > show all tasks > > Sho

rpctrace on a statically linked executable

Hi - I'm confused by rpctrace's behavior on a statically linked test program. Here's the program: #include int main(int argc, char *argv[]) { printf("Hello world!\n"); } Perhaps you've seen it before :-) When I compile the program with -static, I get an executable that works fine, but can't

RFC: kernel trace facility

I've had so many problems with rpctrace that I'm starting work on a kernel trace facility, and I think the consensus on this list is that we need something like this. Here's the idea. Add a trace port as a new task special port. The same RPCs that get/set task ports and exception ports will be u

Re: Personal Introduction

Charlie - Welcome to Hurd! I'm not sure what you consider a small task. Perhaps you could look at my March 9th email to this list, entitled "RFC: kernel trace facility". Briefly, I want to instrument the kernel so that we can trace the messages going to and from a particular task. Our current w

Re: Personal Introduction

On Thu, Apr 5, 2018 at 11:20 AM, Charlie Sale 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 rea

Re: Personal Introduction

On Thu, Apr 5, 2018 at 6:53 PM, Samuel Thibault wrote: > Brent W. Baccala, le jeu. 05 avril 2018 18:42:24 -0400, a ecrit: > > > that the Debian maintainers have threatened to drop us completely unless > we get > > our code upstreamed into the main glibc code base. > >

Re: Personal Introduction

On Thu, Apr 5, 2018 at 7:27 PM, Samuel Thibault wrote: > Brent W. Baccala, le jeu. 05 avril 2018 19:06:23 -0400, a ecrit: > > Yes, Mach is > sort of an exception, because it was merely the ground for the whole > kernel. But being BSD-licenced, it was not posing problems

Hurd SSI paper

FYI - I had a request to write a paper documenting my work on Hurd, so I did. It's called "Building an SSI Cluster with GNU/Hurd" and it's available here: https://www.freesoft.org/software/hurd/building.pdf The LaTeX source is also in the github repository (link in the paper). Feedback is welco

Re: Hurd SSI paper

On Mon, Jun 17, 2019 at 4:12 AM Joan Lledó wrote: > Hi Brent, > > I've only read the introduction sections for now, but I found a little > typo: the title of the paper says: "Building an SSI *Cluter* with > GNU/Hurd", shouldn't it be "Cluster"?, it lacks the 's'. > Perhaps a Freudian slip? Than

Re: Hurd SSI paper

On Sat, Jun 15, 2019 at 11:05 AM Almudena Garcia wrote: > Great job!! I'm reading the paper, looks very good. > > I'm working in SMP support, using xAPIC (32 bit yet). Your work makes more > sense to my project :-) > You can find my work here: https://github.com/AlmuHS/GNUMach_SMP > I haven't be

<    1   2