[Top][All Lists]

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

Re: A small patch for the Hurd Reference Manual

From: Joshua Branson
Subject: Re: A small patch for the Hurd Reference Manual
Date: Mon, 28 Sep 2015 08:53:03 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

Hello Olaf,

I've modified my patch.diff to fix the problems you had with the first draft. Namely I,

1) Added my .gitignore back to the diff. BUT that means that I've added some lines to the .gitignore, because I ran texi2pdf inside the hurd/doc directory. If it is not advisable to add more lines to the .gitignore, then I can fix that as well.

2) I fixed the section on sharing microkernel devices between two running hurds. I pretty much copied verbatim what you said in the last email. I hope you don't mind.

3) I removed the "when you're finished here..." paragraph. That was an error on my part.

4) And I removed the reboot line from the shutdown section, because the "running the hurd" in the qemu section on the wiki says to NOT reboot the hurd to avoid file-system corruption.

On 09/26/2015 09:24 AM, Olaf Buddenhagen wrote:

On Fri, Sep 25, 2015 at 01:52:25PM -0400, Joshua Branson wrote:

diff --git a/.gitignore b/.gitignore
deleted file mode 100644
Not sure what happened to your .gitignore -- but you definitely don't
want this in the patch :-)

+Note that it is impossible to share microkernel devices between
+two running Hurds.  If you do not know what you are doing, this could
+cause serious harm.  For example, two hurds with two filesystems
+writing to the same partition will wreak havoc.  In the same way, two
+hurds reading from the same terminal device will not share nicely.
It probably should be mentioned though that sharing *is* possible for
network devices. The different pfinet instances will just pick the
packets applying to them, based on IP.

There is also a "proper" user-space multiplexer for network devices now,
called eth-multiplexer. This is only needed though if you also want to
allow network traffic between the Hurd instances uning the device in
question, rather than just each of them communicating with other

+When you're finished testing your new Hurd, then you can run the
+@command{halt} or @command{reboot} programs to return control to the
+parent Hurd.
I don't think this really belongs here?...


Attachment: patch.diff
Description: Text Data

reply via email to

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