From 2603401fa1f899a8ff60ec6a134d5bd511073a9d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 7 Aug 2012 23:25:26 +0200 Subject: IRC. --- hurd/subhurd/discussion.mdwn | 96 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 93 insertions(+), 3 deletions(-) (limited to 'hurd/subhurd') diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn index 3449edcd..c4fc047f 100644 --- a/hurd/subhurd/discussion.mdwn +++ b/hurd/subhurd/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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 @@ -8,9 +8,10 @@ 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]] +[[!tag open_issue_documentation open_issue_hurd]] -IRC, freenode, #hurd, 2011-08-10 + +# IRC, freenode, #hurd, 2011-08-10 < braunr> youpi: aren't sub-hurds actually called "neighbor hurds" ? < youpi> no idea @@ -67,3 +68,92 @@ IRC, freenode, #hurd, 2011-08-10 < 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 + + +# IRC, freenode, #hurd, 2012-07-31 + + subhurd seems like bsd jail (tried none of them) + gg0: nope. BSD jails are mostly chroot AIUI. subhurd is quite + different + gg0: you actually boot a completely new system instance + complete with all the Hurd servers, UNIX daemons etc. + jails are between subhhurds and chroots :p + i suppose there is nothing against making the root server of the + subhurd use a file instead of a raw disk, is there ? + well, I said jails cos afaik are more isolated from real system than + chroots + yes + maybe comparing subhurd to virtual machines would be more + appropriated then + they're not VMs either + say chroot -> jail -> subhurd -> vm ? + unless you consider the microkernel to be a hypervisor, with its + own architecture, which some actually do + gg0: something like that, yes + [system-in-system evolution] + a subhurd is an operating system instance + i think the closest analogy you can get is openvz + yeah, I'd also consider it closest. but it's still quite + different: with OpenVZ, the kernel facilities are only logically + isolated; but they use the same kernel code. with subhurds, most of the + system facilities are independent + + +# IRC, freenode, #hurd, 2012-08-03 + + hm... are Mach task IDs exposed to userspace? + antrik: ids ? + antrik: what do you call a mach task id ? + task have numeric IDs in the kernel + I wonder whether these are ever exposed to userspace + i'm not sure + i don't remember the had numeric IDs + they* + well, perhaps I'm making things up... but I believe I saw such IDs + in the debugger and/or in error messages + probably their address + or creation time orpc_sample + braunr: well, any unique ID would do + antrik: yes but i was wondering what kdb would actually show + I just realised that it would be useful for debugging accross + subhurds or kernel/userspace if some kind of unique task IDs could be + shown in ps output + yes + this requires some thought though + ps shouldn't show that + there should be mach specific commands i suppose + but then, gdb and other tools wouldn't have access to subhurd + tasks either + why shouldn't ps show that? I don't think it's any more sensitive + information than all the other stuff ps shows... + it doesn't feel right + i would want my system instances to be truely isolated + and use special "cross instance" facilities + when necessary + that's completely orthogonal to what I'm talking about + like eth-multiplexer + you seem to be talking about security + or privacy + we discussed such options when zhengda worked on rootless subhurd + no, I'm talking about convenient debugging + right + i don't think it'zs orthogonal here + if we increase separation, it becomes less convenient + for debugging purposes you would *not* use the isolation options + ok so you propose two modes of operations + BTW, as an isolated subhurd relies on the parent, it makes no + sense to hide subhurd tasks from the parent hurd -- only hide parent hurd + task from the subhurd + agreed + so even with an isolated subhurd global task IDs would still be + useful + + +# IRC, freenode, #hurd, 2012-08-06 + + antrik: if i'm right, the root file system executable is read from + the parent, right ? + braunr: probably... I'm not sure about that part + antrik: i've installed the same packages in both the main and + subhurds to be sure + and to have the right binary and debugging symbols in gdb anyway -- cgit v1.2.3