From 3e7472b3d54853389cd8a17475901fbef976ef18 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 1 Sep 2011 09:27:33 +0200 Subject: IRC. --- hurd/subhurd/discussion.mdwn | 69 ++++++++++++++++++++++++++ hurd/translator/discussion.mdwn | 25 ++++++++++ hurd/translator/procfs/jkoenig/discussion.mdwn | 23 +++++++++ 3 files changed, 117 insertions(+) create mode 100644 hurd/subhurd/discussion.mdwn create mode 100644 hurd/translator/discussion.mdwn (limited to 'hurd') diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn new file mode 100644 index 00000000..3449edcd --- /dev/null +++ b/hurd/subhurd/discussion.mdwn @@ -0,0 +1,69 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-08-10 + + < braunr> youpi: aren't sub-hurds actually called "neighbor hurds" ? + < youpi> no idea + < braunr> i also don't understand the recursive property + < youpi> a user can run a subhurd + < neal> braunr: What don't you understand? + < youpi> a user in a subhurd can run a subhurd + < youpi> etc + < braunr> i'm not sure it's really recursive + < neal> youpi: At some point it was observed that you don't strictly + require any resources from the "parent" Hurd. + < neal> youpi: i.e., you could have two Hurds running "directly" on Mach + < youpi> sure + < neal> youpi: Hence neighbor rather than sub + < youpi> but you need to be root for that + < youpi> or else your subhurd can't do much + < neal> you need to have been authorized to use the required resouces + < youpi> which is about the same :) + < neal> depends how they are delegated + < youpi> that's still asking root for something + < neal> if you say so + < youpi> which is most probably not the default + < braunr> well, either you depend on the parent to do things on your + behalf, or you directly have some privileged ports + < braunr> i'd agree with youpi that it's pretty much having root access at + some point + < youpi> and usually you don't have privileged ports by default :) + < braunr> but we don't need to restrict the presentation to user only sub + hurds + < braunr> people don't mind switching to root on their desktops + < braunr> which is one of the reasons they ask "what does the hurd really + bring me today ?" + < braunr> but being able to run truely separate hurds or recursive hurds is + something nice most OSes can't do easily + < youpi> switching to root becomes a *pain* when you have to do it 1 every + two commands + < braunr> yes sure, but some people might just say you're clumsy :x + < neal> The question is: can I start a sub-hurd from within another hurd + that survives the parent's hurd exiting? The answer is yes. The reason + is that the sub-hurd can be constructed in such a way that it does not + rely on the parent. In this case, the parent does not necessarily + subjugate the sub-hurd. Hence the name. + < braunr> but that's out of the scope of the discussion + < antrik> using the traditional, root only mechanism, neighbour-hurd is + indeed a more appropriate term. apart from the initial terminal being + proxied to the parent system by the boot program, they are really equal + < antrik> with zhengda's work on non-root subhurds, you rely on various + proxies in the parent system to access privileged resources; so subhurd + is indeed a more appropriate term in this case + < antrik> (not only non-root subhurds in fact... when using any of the + proxies, such as the network multiplexer -- even if still running as + root...) + < youpi> antrik: you could still give a com0 port as terminal + < antrik> I don't think that's actually supported in the boot + program... but it doesn't really matter, as you don't really need the + terminal anyways -- you can always log in through the network diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn new file mode 100644 index 00000000..e038ba84 --- /dev/null +++ b/hurd/translator/discussion.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation open_issue_hurd]] + +IRC, freenode, #hurd, 2011-08-25: + + < frhodes> how can I replace an existing running server with a new one + without rebooting? + < antrik> frhodes: depends. if other critical things depend on it, you + can't. there is no mechanism to serialize and pass on the open sessions + < antrik> in some situations, you can orphan the old translator while + starting a new one, so the previous clients will stay with the old one + while new one will get the new one + < antrik> obviously that only works for things that aren't exclusive by + nature + < antrik> in some cases, you might even be able simply to remove the old + translator... but obviously only for non-critical stuff :-) diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 64e3776e..01bbea42 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -184,3 +184,26 @@ IRC, freenode, #hurd, 2011-07-22 status is 644 though but status contains information which anyone can ask to the proc server anyway, I think. + + +# `/proc/mounts`, `/proc/$pid/mounts` + +IRC, freenode, #hurd, 2011-07-25 + + < pinotree> jkoenig: btw, what do you think about providing empty + /proc/mounts and /proc/$pid/mounts files? + < jkoenig> pinotree, I guess one would have to evaluate the consequences + wrt. existing use cases (in other words, "I have absolutely no clue + whatsoever about whether that would be desirable" :-) + < jkoenig> pinotree, the thing is, an error message like "/proc/mounts: No + such file or directory" is rather explicit, whereas errors which would be + caused by missing data in /proc/mounts would maybe be harder to track + < braunr> this seems reasonable though + < braunr> there already are many servers with e.g. grsecurity or chrooted + environments where mounts is empty + < pinotree> well, currently we also have an empty mtab + < braunr> pinotree: but what do you need that for ? + < braunr> pinotree: the init system ? + < pinotree> and the mnt C api already returns no entries (or it bails out, + i don't remember) + < pinotree> not a strict need -- cgit v1.2.3