From 2603401fa1f899a8ff60ec6a134d5bd511073a9d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 7 Aug 2012 23:25:26 +0200 Subject: IRC. --- hurd/debugging/rpctrace.mdwn | 8 +++ hurd/subhurd/discussion.mdwn | 96 +++++++++++++++++++++++++- hurd/translator.mdwn | 2 + hurd/translator/ext2fs.mdwn | 2 + hurd/translator/ext2fs/internal_allocator.mdwn | 39 +++++++++++ hurd/translator/firmlink.mdwn | 22 ++++++ hurd/translator/procfs/jkoenig/discussion.mdwn | 3 + 7 files changed, 169 insertions(+), 3 deletions(-) create mode 100644 hurd/translator/ext2fs/internal_allocator.mdwn create mode 100644 hurd/translator/firmlink.mdwn (limited to 'hurd') diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index df6290f7..c506861a 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -167,6 +167,14 @@ See `rpctrace --help` about how to use it. Debian-specific, but not ready for upstream either... antrik: yes +* IRC, freenode, #hurd, 2012-07-18 + + hm, rpctrace on gitk gives an interesting result + 152<--153(pid1849)->io_set_all_openmodes_request (267) = 0 + rpctrace: + /home/rbraun/hd0s7/hurd/hurd-20120710/./utils/rpctrace.c:1287: + trace_and_forward: Assertion `reply_type == 18' failed. + # See Also 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 diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index d504b41f..37f4e8bc 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -93,6 +93,8 @@ The [[concept|concepts]] of translators creates its own problems, too: * [[magic]] * [[unionfs]] * [[nfs]] +* [[symlink]] +* [[firmlink]] * ... diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index 8e15d1c7..460194f9 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -20,6 +20,8 @@ License|/fdl]]."]]"""]] * [[metadata_caching]] + * [[internal_allocator]] + ## Large Stores diff --git a/hurd/translator/ext2fs/internal_allocator.mdwn b/hurd/translator/ext2fs/internal_allocator.mdwn new file mode 100644 index 00000000..f3678a28 --- /dev/null +++ b/hurd/translator/ext2fs/internal_allocator.mdwn @@ -0,0 +1,39 @@ +[[!meta copyright="Copyright © 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 +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, 2012-07-30 + + Why for big buffers in ext2fs used own allocator, that just + allocates many pages at once, instead of using malloc? + i.e. can I replace it with malloc, because it just complicates + things? + mcsim: probably because of alignment + what gets complicated by that ? + braunr: than valloc? + braunr: this allocator allows to allocate only buffer with size of + vm_page_size. + valloc just would be clearer. + valloc ? + valloc is obsolete + braunr: than memalign or posix_memalign? + memalign obsolete too... would posix_memalign be eligible? + mcsim: why memalign instead of the custom allocator ? + because, I think, it is clearer. Also, since I need to allocate any + amount of pages, not just one, I have to edit custom allocator. Although + it is not hard, but using ready stuff seems more sane for me. + braunr: ^ + right, but make sure posix_memalign doesn't create too much + overhead + braunr: what kind of overhead? + fragmentation + i assume the glibc implementation is careful about that, but still diff --git a/hurd/translator/firmlink.mdwn b/hurd/translator/firmlink.mdwn new file mode 100644 index 00000000..038879db --- /dev/null +++ b/hurd/translator/firmlink.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 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 +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, 2012-07-20 + + does hurd have equivalent of mount --bind yet? + infinity0: unionfs with just one back-end ? + ah cool i'll try thaty + there may be something better, but that's the one I know about ;) + infinity0: firmlinks + ah thanks i'll look that up + braunr: oh, true, I forgot about that one diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 182b438b..0ee1e238 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -281,6 +281,9 @@ Needed by glibc's `pldd` tool (commit # `/proc/[PID]/maps` +[[!tag GNU_Savannah_bug 32770]] + + ## IRC, OFTC, #debian-hurd, 2012-06-20 bdefreese: the two elfutils tests fail because there are no -- cgit v1.2.3