diff options
Diffstat (limited to 'open_issues')
| -rw-r--r-- | open_issues/debugging.mdwn | 2 | ||||
| -rw-r--r-- | open_issues/debugging_gnumach_startup_qemu_gdb.mdwn | 116 | ||||
| -rw-r--r-- | open_issues/gnumach_constants.mdwn | 32 | ||||
| -rw-r--r-- | open_issues/gnumach_kernel_threads.mdwn | 23 | ||||
| -rw-r--r-- | open_issues/gnumach_memory_management.mdwn | 65 | ||||
| -rw-r--r-- | open_issues/placement_of_virtual_memory_regions.mdwn | 89 | ||||
| -rw-r--r-- | open_issues/rework_gnumach_ipc_spaces.mdwn | 197 | ||||
| -rw-r--r-- | open_issues/translate_fd_or_port_to_file_name.mdwn | 36 | ||||
| -rw-r--r-- | open_issues/xattr.mdwn | 27 |
9 files changed, 570 insertions, 17 deletions
diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn index e5fbf7a0..b2d49b26 100644 --- a/open_issues/debugging.mdwn +++ b/open_issues/debugging.mdwn @@ -49,3 +49,5 @@ We have debugging infrastructure. For example: * <http://lwn.net/Articles/415728/>, or <http://lwn.net/Articles/415471/> -- just two examples; there's a lot of such stuff for Linux. + + * [[debugging_gnumach_startup_QEMU_GDB]] diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn new file mode 100644 index 00000000..e3a6b648 --- /dev/null +++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn @@ -0,0 +1,116 @@ +[[!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]]."]]"""]] + +[[!meta title="Debugging GNU Mach's startup in QEMU with GDB"]] + +[[!tag open_issue_gdb open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2011-07-14 + + <mcsim> Hello. I have problem with debugging gnumach. I set 2 brakepoints + in file i386/i386at/model_dep.c on functions gdt_init and idt_init. Then + I start qemu with patched gnumach kernel and stop at gdt_init. When I + enter command "continue" in gdb, qemu hangs. But when I go step by step, + using command "next", I freely reach idt_init. What can cause this + problem? + <braunr> hm + <braunr> not sure + <braunr> let me try + <braunr> mcsim: works for me :/ + <mcsim> it works without my patch, but with it qemu hangs + <braunr> oh, i thought it worked when not using continue + <mcsim> with my patch I can reach idt_init only using next + <mcsim> and without all works fine + <braunr> mcsim: are you sure you correctly built it with debugging symbols + ? + <mcsim> I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0 + <braunr> hm + <braunr> i have internal kvm errors actually + <braunr> mcsim: do you use kvm ? + <braunr> mcsim: and why break on those functions ? + <braunr> i'm not sure the address space is already fine at this point + <mcsim> no. I don't have hardware virtualisation support. + <braunr> hm actually, you won't be able to use gdb + <braunr> i just remembered how gnumach is linked and mapped :/ + <braunr> the addresses in the elf image are low addresses, matching the + image as it is loaded by the boot loader + <mcsim> I was wondering why qemu hangs. + <braunr> then the kernel uses segmentation to map itself at 2 (or 3 + previously) GiB + <braunr> well, if the addresses are wrong, your breakpoints are wrong + <braunr> i even wonder how it can work when stepping + <braunr> i don't have the issue with x15 because of its linker script + <mcsim> Are there any ways of such debugging without qemu? + <braunr> i don't think so + <braunr> as antrik told you, the in kernel debugger needs many services + running before being usable + <braunr> you'll have to use printf, and there may be steps during bootstrap + when even that isn't available + <mcsim> So I need computer with hardware virtualisation? + <braunr> well, of course stepping works, since the breakpoints are relative + <braunr> no + <braunr> kvm has nothing to do with the problem + <braunr> it's just that the problem appears differently with kvm enabled + <mcsim> ok. thank you. + <braunr> good luck + <antrik> braunr: would it be hard to "fix" gnumach to avoid the + segmentation magic?... + <braunr> antrik: because of the linux drivers, it may + <antrik> or alternatively, implement something in GDB to deal with that?... + <braunr> antrik: i didn't study that part enough to know for sure + <antrik> uhm... why would the Linux drivers depend on that? does Linux also + do such magic?... + <braunr> well it should simply be a matter of shifting the address by a + fixed offset + <braunr> antrik: linux drivers rely on physical memory being allocated + through kmalloc + <braunr> so there must be a direct mapping between virtual kernel memory + and physical memory + <braunr> they don't specifically need that segmentation settings + <braunr> so if you remove the offset implemented through segmentation, you + have to replace it with page mapping + <braunr> and i don't know how much needs to be done for that + <braunr> you also need to link the kernel differently + <antrik> hm, OK + <antrik> so adding GDB support for the offset would probably be easier... + <braunr> yes + <braunr> but using the offset must only be done once segmentation is set up + <braunr> so you must break after gdt_init + <braunr> not on it + <braunr> mcsim: why do you break on these functions btw ? + <mcsim> I just wanted to find out why qemu hangs + <braunr> yes but why those ? + <mcsim> I found out that before gdt_init all workes fine, but after qemu + hangs. So idt_init is just the next function + <braunr> ok + <braunr> and does your patch change something to how segmentation is + initialized ? + <mcsim> now + <mcsim> no + <braunr> try to build it with the regular cflags + <braunr> i don't know if gnumach can work with -O0 + <mcsim> I've tried. But all the same + <mcsim> Regular are -g -O2 + <braunr> can you make your patch available ? + <mcsim> yes + <mcsim> it is available in gnumach repository at savannah + <mcsim> tree mplaneta/libbraunr/master + <antrik> well, if the segmentation stuff is the thing GDB has problems + with, I don't see how it can work without your patch... + <braunr> without ? + <antrik> well, the patch shouldn't affect the segmentation... so I don't + see how it can make a difference + <braunr> he said qemu hanged + <braunr> so let's not introduce gdb yet + <braunr> qemu can hang for other reasons + <antrik> oh, right, without GDB... + <antrik> though if that's what he meant, his statement was very misleading + at least diff --git a/open_issues/gnumach_constants.mdwn b/open_issues/gnumach_constants.mdwn new file mode 100644 index 00000000..16c8cf41 --- /dev/null +++ b/open_issues/gnumach_constants.mdwn @@ -0,0 +1,32 @@ +[[!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_gnumach]] + +At compile-time, GNU Mach is parameterized with several constants. These might +need some tuning. Debian has some patches. + + +# IRC, freenode, #hurd, 2011-06-09 + + <braunr> youpi: in ipc/ipc_hash.c, there is code which computes the size of + the global (space, port)->entry hash table + <braunr> youpi: you may be interested in tuning this one too + <youpi> I know + <braunr> ok + <youpi> the current value is not so bad + <youpi> it's big enough for buildds to run fine + <braunr> 256 if i'm right + <braunr> well + <braunr> it won't fail + <youpi> we're limited by the 4000 object limitation anyway + <braunr> since it's a chained hash table + <braunr> but increasing it may help performances a bit + <braunr> and it certainly can't hurt much diff --git a/open_issues/gnumach_kernel_threads.mdwn b/open_issues/gnumach_kernel_threads.mdwn new file mode 100644 index 00000000..9591986b --- /dev/null +++ b/open_issues/gnumach_kernel_threads.mdwn @@ -0,0 +1,23 @@ +[[!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_gnumach]] + +IRC, freenode, #hurd, 2011-07-13 + + <braunr> jkoenig: why does gnumach appear as "root=device:hd0s1" in ps ? + <jkoenig> braunr, it's the closest we can do to its command line + <braunr> doesn't it deserve something special like kernel threads in linux + ? + <braunr> so that it's actually clear that it's a special task/process + <jkoenig> you mean something like [mach root=device:hd0s1] ? + <braunr> something like that yes + <braunr> also, it would be nice if gnumach threads could actually be seen, + i don't remember if the mach interface allows it though diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index a5dd6955..f15c4d25 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -12,7 +12,10 @@ License|/fdl]]."]]"""]] There is a [[!FF_project 266]][[!tag bounty]] on this task. -IRC, freenode, #hurd, 2011-04-12: +[[!toc]] + + +# IRC, freenode, #hurd, 2011-04-12 <antrik> braunr: do you think the allocator you wrote for x15 could be used for gnumach? and would you be willing to mentor this? :-) @@ -597,7 +600,8 @@ IRC, freenode, #hurd, 2011-04-12: <mcsim> It would be better to rewrite it using debugfs, but when I was writing this test I didn't know about trace_* macros -2011-04-15 + +# IRC, freenode, #hurd, 2011-04-15 <mcsim> There is a hack in zone_gc when it allocates and frees two vm_map_kentry_zone elements to make sure the gc will be able to allocate @@ -632,7 +636,8 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> i think that's why i have "sources" in my slab allocator, the default source (vm_kern) and a custom one for kernel map entries -2011-04-18 + +# IRC, freenode, #hurd, 2011-04-18 <mcsim> braunr: you've said that once page is completely free, it is returned to the vm. @@ -640,7 +645,8 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> mcsim: i also said i was wrong about that <braunr> zone_gc is the only one -2011-04-19 + +# IRC, freenode, #hurd, 2011-04-19 <braunr> antrik: mcsim: i added back a new per-cpu layer as planned <braunr> @@ -649,7 +655,8 @@ IRC, freenode, #hurd, 2011-04-12: loops, just as in zone_gc, to reduce contention and avoid deadlocks <braunr> this is really common in memory allocators -2011-04-23 + +# IRC, freenode, #hurd, 2011-04-23 <mcsim> I've looked through some allocators and all of them use different per cpu cache policy. AFAIK gnuhurd doesn't support multiprocessing, but @@ -661,7 +668,8 @@ IRC, freenode, #hurd, 2011-04-12: <antrik> I'm not sure I suggested that explicitly to you; but probably it makes most sense to use that in gnumach -2011-04-24 + +# IRC, freenode, #hurd, 2011-04-24 <mcsim> antrik: Yes, I have. He uses both global and per cpu caches. But he also suggested to look through slqb, where there are only per cpu @@ -773,7 +781,8 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> the fact that the kernel allocator uses virtual memory doesn't mean the kernel has no mean to allocate contiguous physical memory ... -2011-05-02 + +# IRC, freenode, #hurd, 2011-05-02 <braunr> hm nice, my allocator uses less memory than glibc (squeeze version) on both 32 and 64 bits systems @@ -822,7 +831,8 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> it could also be used to drop the overloaded (and probably over imbalanced) page cache hash table -2011-05-03 + +# IRC, freenode, #hurd, 2011-05-03 <mcsim> antrik: How should I start porting? Have I just include rbraun's allocator to gnumach and make it compile? @@ -845,3 +855,42 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> there is work to be done ;) <braunr> (not to mention the obvious about replacing all the calls to the zone allocator, and testing/debugging afterwards) + + +# IRC, freenode, #hurd, 2011-07-14 + + <braunr> can you make your patch available ? + <mcsim> it is available in gnumach repository at savannah + <mcsim> tree mplaneta/libbraunr/master + <braunr> mcsim: i'll test your branch + <mcsim> ok. I'll give you a link in a minute + <braunr> hm why balloc ? + <mcsim> Braun's allocator + <braunr> err + <braunr> + http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=kern/kmem.c;h=37173fa0b48fc9d7e177bf93de531819210159ab;hb=HEAD + <braunr> mcsim: this is the interface i had in mind for a kernel version :) + <braunr> very similar to the original slab allocator interface actually + <braunr> well, you've been working + <mcsim> But I have a problem with this patch. When I apply it to gnumach + code from debian repository. I have to make a change in file ramdisk.c + with sed -i 's/kernel_map/\&kernel_map/' device/ramdisk.c + <mcsim> because in git repository there is no such file + <braunr> mcsim: how do you configure the kernel before building ? + <braunr> mcsim: you should keep in touch more often i think, so that you + get feedback from us and don't spend too much time "off course" + <mcsim> I didn't configure it. I just run dpkg-buildsource -b. + <braunr> oh you build the debian package + <braunr> well my version was by configure --enable-kdb --enable-rtl8139 + <braunr> and it seems stuck in an infinite loop during bootstrap + <mcsim> and printf doesn't work. The first function called by c_boot_entry + is printf(version). + <braunr> mcsim: also, you're invited to get the x15mach version of my + files, which are gplv2+ licensed + <braunr> be careful of my macros.h file, it can conflict with the + macros_help.h file from gnumach iirc + <mcsim> There were conflicts with MACRO_BEGIN and MACRO_END. But I solved + it + <braunr> ok + <braunr> it's tricky + <braunr> mcsim: try to find where the first use of the allocator is made diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn new file mode 100644 index 00000000..95b9e545 --- /dev/null +++ b/open_issues/placement_of_virtual_memory_regions.mdwn @@ -0,0 +1,89 @@ +[[!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_gnumach]] + +IRC, freenode, #hurd, 2011-07-13 + + <braunr> does anyone know if posix (or mach) has requirements or a policy + about the placement of allocations of virtual space ? + <braunr> a policy such as bottom-up ? + <braunr> or "find lowest vailable space" ? + <jkoenig> braunr, you mean for vm_allocate ? You may want to check mmap() + but I can't remember ever coming across such a thing (except maybe + wrt. alignment) + <braunr> i was wondering how e.g. libraries are linked near the stack + (possibly at slightly random addresses) + <braunr> does the linker walk the address space entries top-down ? + <braunr> jkoenig: i didn't see anything either in the mach interface, but i + may have missed something + <braunr> jkoenig: most systems i've been studying mark the vm regions for + the heap and the stack + <braunr> but for mach, the stack is just allocated virtual memory at the + top of the space + <braunr> so the "placement policy" is either completely outside the kernel, + or relies on its interface + <jkoenig> braunr, actually I'm surprised Mach would even dictate where the + (one?) stack should be, I would have expected it to be the job of + whatever creates a thread to make this kind of choice + <braunr> jkoenig: threads have their own stacks, under the responsibility + of the user trhead implementation + <braunr> but a program usually needs a stack even before it runs + <braunr> i had to set one to bootstrap modules in v0.1 + <braunr> but i wonder if it's just for bootstrapping (and then propagated + by fork()) or part of the interface + <braunr> but this doesn't matter much actually, the allocation mechanism i + have in mind can actually support multiple policies + <jkoenig> I would guess the former (just for bootstrapping), since a new + task has no thread, and a new thread has no state. (but I'm no expert) + <braunr> i think so + <braunr> i'll have a look at the exec server + <braunr> jkoenig: did the previous implementation of procfs show task maps + ? + <jkoenig> braunr, I don't think so, I would probably have felt compelled to + include them in the new one if it did :-) + <braunr> hmmm + <braunr> we definitely need that + <jkoenig> is there a compelling use case you think about in particular? + <braunr> yes + <braunr> i failed to understand how gnumach behaved wrt ipc right spaces + +[[rework_gnumach_ipc_spaces]] + + <braunr> and when i did, i found out my work was impossible to integrate + <jkoenig> "ipc right spaces" ? + <braunr> each task have an ipc space, which contains righs + <braunr> rights + <braunr> the ipc translation layer converts space/name and space/port + tuples to rights + <braunr> i wanted to replace the splay tree with a radix tree but didn't + get how the ipc table made the splay tree almost unused + <braunr> i don't want to make this kind of mistake again, so i'd like a + clear and detailed view of the vm spaces + <braunr> (it's only compelling for myself, all right) + <braunr> but + <braunr> we have vminfo + <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l + <braunr> 1046 + <braunr> oh my + <braunr> in comparison, a firefox instance has less than 500 on linux + <jkoenig> you mean there's some kind of port name table (or functional + equivalent) which actually resides in the task's memory? (and that's what + shows up at the beginning of the address space with prot=0?) + <braunr> jkoenig: sorry for being confusing, it's not that at all + <jkoenig> (btw feel free to tell me to just go read the source or whatever) + <braunr> jkoenig: don't worry + <jkoenig> braunr, no problem + <braunr> jkoenig: i just compared a previous attempt to improve gnumach + which failed because i didn't have enough insight of the inner workings + of the kernel + <braunr> jkoenig: i really want to miss as little as possible on the vm + part, so having detailed information about what actually happens on + running hurd systems is something i need diff --git a/open_issues/rework_gnumach_ipc_spaces.mdwn b/open_issues/rework_gnumach_ipc_spaces.mdwn index f5d40abd..b3d1b4a4 100644 --- a/open_issues/rework_gnumach_ipc_spaces.mdwn +++ b/open_issues/rework_gnumach_ipc_spaces.mdwn @@ -10,7 +10,10 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] -IRC, freenode, #hurd, 2011-05-07 +[[!toc] + + +# IRC, freenode, #hurd, 2011-05-07 <braunr> things that are referred to as "system calls" in glibc are actually RPCs to the kernel or other tasks, those RPCs have too lookup @@ -20,7 +23,8 @@ IRC, freenode, #hurd, 2011-05-07 There is a [[!FF_project 268]][[!tag bounty]] on this task. -IRC, freenode, #hurd, 2011-04-23 + +# IRC, freenode, #hurd, 2011-04-23 <braunr> youpi: is there any use of the port renaming facility ? <youpi> I don't know @@ -250,7 +254,8 @@ IRC, freenode, #hurd, 2011-04-23 <antrik> well, if some processes really feel they must use random numbers for port names, they *ought* to be penalized ;-) -2011-04-27 + +# IRC, freenode, #hurd, 2011-04-27 <braunr> antrik: remember when you asked why high numbers would be a problem with radix trees ? @@ -319,7 +324,182 @@ IRC, freenode, #hurd, 2011-04-23 <braunr> antrik: a data structure used to map integers to pointers <braunr> http://fxr.watson.org/fxr/source/lib/idr.c?v=linux-2.6 -2011-06-18 + +# IRC, freenode, #hurd, 2011-06-08 + + <braunr> hm, reverse space/port to name lookups also suck + <braunr> having separate types for simple ipc entries and splay tree + entries really makes many parts of the ipc code complicated + <braunr> and a global hash table for these operations is scary + + +# IRC, freenode, #hurd, 2011-06-09 + + <braunr> hm nice, my radix tree code runs inside gnumach, along with the + original splay tree code and assertions making sure results are the same + <braunr> there is this "collision" thing i'm not sure to understand but + once this is solved, replacing the splay trees should be easy + + <braunr> youpi: is there a way to easily know the number of send rights + associated to a port ? + <youpi> portinfo ? + <braunr> portinfo gives information in a space + <braunr> but this is specific to a port + <braunr> is there an option for that ? + <youpi> -v + <braunr> hm ok + <youpi> 25: send (refs: 550) + <braunr> nice + <braunr> youpi: if you have time, could you give me the min/max/avg numbers + of send rights referring to the same port on buildds ? + <braunr> i'm trying to estimate if it's better to have space->list_of_ports + or port->list_of_spaces to replace the global ipc hash table + <braunr> the latter seems better but there could be unexpected cases on + machines using large amounts of resources like the buildds + <youpi> max is 64k + <youpi> min is 1 of course :) + <braunr> 64k + <braunr> then it's not what i'm looking for + <youpi> avg is 55 + <braunr> isn't this the number of urefs ? + <youpi> I don't know + <braunr> hmm + <braunr> what i'm looking for is the number of *pure send rights* for the + same port + <braunr> i don't think portinfo can give it + <braunr> there can only be one such send right per task for the same port + <braunr> 64k would mean there are 64k tasks + <youpi> ok, so it's more difficult + <youpi> it means using -t + <braunr> ahh + <youpi> and run n^2 portinfo over the n processes + <braunr> i see + <youpi> Mmm, that will however still show any duplicate send right + <youpi> but then by min/max/avg, you mean, over time ? + <braunr> i'll change the source code, simpler + <youpi> e.g. min would be right after boot? + <braunr> min is 1 + <youpi> 1 what ? + <braunr> 1 send right to a port + <youpi> ah, 1 for a given port + <braunr> yes + <youpi> ok, it becomes really hairy to compute, I don't hav ethe time :) + <braunr> avg and max are more interesting :) + <braunr> no worries + <youpi> braunr: I wouldn't be surprised that max is the number of tasks + <youpi> e.g. for a send port to the proc server for instance + <braunr> youpi: it is, but i'm not looking for potential numbers + <youpi> I'm not talking about a potential number, but an actual number + that's almost always true + <braunr> for one port, yes + <braunr> but yes, ok for max + <braunr> this makes choosing an appropriate data structure difficult + + <antrik> braunr: actually, min number of send rights to a port is 0... but + I'm sure you know that already :-) + + <antrik> youpi: normally each client gets a separate port. I'm not sure + there are any ports with send rights distributed over many tasks... + + <jkoenig> antrik, what about / ? + + <youpi> antrik: not necessarily + + <antrik> jkoenig: not sure... isn't the "/" port authenticated to the + specific user? + + <jkoenig> antrik, I guess so, but a single user could still have many + tasks. + <jkoenig> (wrt /) + <antrik> jkoenig: well, in theory the tasks having exactly the same UIDs + and GITs could probably share an auth token... but that's not how things + are handled in general + <antrik> at least I don't think so + <antrik> tasks are authenticated, not users + <antrik> err... GIDs :-) + <jkoenig> antrik, still, my quick glance to the fork() code seemed to + indicate the port is inherited as-is, maybe authentication happens only + when something is actually looked up? + <jkoenig> hmm "rpctrace ls -d /" does not show any authentication calls, + only a lookup("") on the root which returns a different port + <jkoenig> so I guess the root port is "deauthenticated" or something when + the uid of a process is changed. + <antrik> too bad cfhammer isn't around, he digged into all this stuff... + <antrik> I know that there is a mechanism which reauths all FDs when the + IDs of a process change + <antrik> but I'm not sure the "/" port uses this mechanism + + <braunr> antrik: but the radix tree codee is really used as is, which means + no locking, no preloading before locking, all of this because simple + locks don't exist on UP, and because the kernel isn't preemptible + + <braunr> antrik: and yes, min number is 0, but in that case you don't need + (space, port) -> right lookups :) + <braunr> antrik: or put in another way, whichever reasonable structure you + use, when it's empty, you don't care much + <braunr> which also means that the min number has actually no value here + <braunr> because the same applies to 1 + + <braunr> then what seems to take most time is forks + <braunr> and i hope my upcoming kernel changes will help the situation a + bit + <pinotree> what are your incoming gnumach changes about? + <braunr> the ipc translation layer speed + <braunr> which basically means operating on port names (looking them up, + inserting, removing, renaming, looking up send rights to a specific + ports) will be faster + <braunr> and i believe forks are (one of) the most demanding use cases wrt + ipc space manipulation + <braunr> i'm really surprised how badly the splay trees are used + <braunr> the worst case for this data structure is traversal + <braunr> and this is done in many situations + <braunr> leaving the tree in its worst case shape + <braunr> and i didn't mentioned the bunch of memory writes occurring, event + for things like lookups or traversals + <braunr> this is slow and can disrupt many cpu cache lines + <braunr> and when there are 10k to 100+k (e.g. in some ext2fs instances on + buildds), just imagine the number of operations involved in those + operations + <braunr> a simple traversal_next involves a rotation *gasp* + <braunr> this means potentially writing on 3 different cache lines, for + *one* next operation + <pinotree> what are you replacing that splay tree with? + <braunr> radix trees + <braunr> much shorter paths + <braunr> extremely few memory writes + <braunr> locality of reference when traversing + <braunr> good cache usage (as many of the top nodes are reused) + <braunr> the two drawbacks are 1/ memory allocation for external nodes, + which means the tree must be preloaded before locking + <braunr> and 2/ high memory overhead if the keys are sparse + <braunr> but this isn't the case with port names, unless someone messes it + up by assigning random names to many rights + + <antrik> braunr: so, when will we see the first performance comparision? + :-) + <braunr> antrik: that's a topic of itself, how to compare ? + <braunr> antrik: the thing is, my current gnumach patches only makes + assertions + <braunr> this is the best way i found to test my tree in real life + conditions + <braunr> much cleanup is needed + <braunr> and what i'd like to do is to completely replace all teh + translation layer structures with it + <braunr> which means removing much code, making sure it still works as + expected + <braunr> this is tedious + <braunr> so one month at least + <antrik> braunr: comparing shouldn't be too hard... the average configure + script does a lot of forking, which should be a good benchmark according + to your observations + <braunr> rough estimates are easy, yes + <braunr> but my observations my be wrong :p + <antrik> braunr: well, we don't really need precise numbers... + <antrik> unless you need to do some kind of fine-tuning? + <braunr> i don't know yet + + +# IRC, freenode, #hurd, 2011-06-18 < braunr> hmm, i'm having a problem with integrating my radix tree code in gnumach @@ -373,7 +553,8 @@ IRC, freenode, #hurd, 2011-04-23 < braunr> not much < braunr> testing is what requires time really -2011-06-27 + +# IRC, freenode, #hurd, 2011-06-27 < braunr> ok, here is the radix tree code: http://git.sceen.net/rbraun/libbraunr.git/ @@ -399,7 +580,8 @@ IRC, freenode, #hurd, 2011-04-23 < youpi> k < braunr> before locking the ipc spaces -2011-06-28 + +# IRC, freenode, #hurd, 2011-06-28 < braunr> antrik: i think i won't write the code for the preloading stuff actually @@ -456,7 +638,8 @@ IRC, freenode, #hurd, 2011-04-23 only < braunr> but released in both the entry and the splay tree code ... -2011-06-29 + +# IRC, freenode, #hurd, 2011-06-29 < braunr> hmm i missed an important thing :/ < braunr> and it's scary diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn index 25a74456..485fb985 100644 --- a/open_issues/translate_fd_or_port_to_file_name.mdwn +++ b/open_issues/translate_fd_or_port_to_file_name.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 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 @@ -10,7 +10,10 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_hurd]] -\#hurd, freenode, June (?) 2010 +[[!toc]] + + +# IRC, freenode, #hurd, June (?) 2010 <pochu> is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port? <marcusb> there is a way @@ -52,3 +55,32 @@ License|/fdl]]."]]"""]] <marcusb> which combines file and directory operations <marcusb> of course, files and directories implement those functions differently <antrik> marcusb: do you know why this behavior (cat on directories) was changed? + + +# IRC, freenode, #hurd, 2011-07-13 + +A related issue: + + <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l + <braunr> 1039 + <braunr> any idea why a shell would consume more than 1039 map entries ? + <braunr> (well, not more actually) + <braunr> even the kernel and ext2fs have around 100 + <braunr> (the kernel has actually only 23, which is very good and expected) + <tschwinge> braunr: I agree that having some sort of debugging information + for memory objects et al. would be quite hand. To see where they're + coming from, etc. + <braunr> tschwinge: this would require naming objects at the mach level + <braunr> e.g. when creating an object + <braunr> giving it the path of a file for example + <tschwinge> braunr: I have recently seen something (due to youpi fixing a + bug) that bash is doing its own memory management. Perhaps all these are + such regions? + <tschwinge> braunr: For example, yes. + <braunr> what ? + <braunr> ?! + <tschwinge> braunr: + http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00097.html + <braunr> i see + +Also see email thread starting at `id:"20110714082216.GA8335@sceen.net"`. diff --git a/open_issues/xattr.mdwn b/open_issues/xattr.mdwn new file mode 100644 index 00000000..8b08ef1e --- /dev/null +++ b/open_issues/xattr.mdwn @@ -0,0 +1,27 @@ +[[!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]]."]]"""]] + +[[!meta title="xattr: extended attributes"]] + +[[!tag open_issue_glibc open_issue_hurd]] + +IRC, freenode, #hurd, 2011-06-01 + + <gnu_srs> Another thing: the lsattr and chattr programs seems to be bogus + on Hurd. Are they present since they are part of e2fsprogs? + <youpi> I don't think the Hurd has an interface for it + <tschwinge> gnu_srs, youpi: lsattr/chattr are extended attributes, right? + We do have some patches from years ago for adding some support in glibc, + but they're not yet integrated. And also we do have a plan for using + these instead of our Hurd-specific passive translator information in + inodes. + +If interested in working on this, see [[!GNU_Savannah_task +#5503]]/[[!GNU_Savannah_patch #5126]], and talk to [[tschwinge]]. |