From 1c8909017d006c8e4afeea6d1a1efdebe26fc6b0 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 15 Jul 2011 22:46:18 +0200 Subject: IRC. --- open_issues/debugging.mdwn | 2 + .../debugging_gnumach_startup_qemu_gdb.mdwn | 116 ++++++++++++ open_issues/gnumach_constants.mdwn | 32 ++++ open_issues/gnumach_kernel_threads.mdwn | 23 +++ open_issues/gnumach_memory_management.mdwn | 65 ++++++- .../placement_of_virtual_memory_regions.mdwn | 89 ++++++++++ open_issues/rework_gnumach_ipc_spaces.mdwn | 197 ++++++++++++++++++++- open_issues/translate_fd_or_port_to_file_name.mdwn | 36 +++- open_issues/xattr.mdwn | 27 +++ 9 files changed, 570 insertions(+), 17 deletions(-) create mode 100644 open_issues/debugging_gnumach_startup_qemu_gdb.mdwn create mode 100644 open_issues/gnumach_constants.mdwn create mode 100644 open_issues/gnumach_kernel_threads.mdwn create mode 100644 open_issues/placement_of_virtual_memory_regions.mdwn create mode 100644 open_issues/xattr.mdwn (limited to 'open_issues') 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: * , or -- 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 + + 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? + hm + not sure + let me try + mcsim: works for me :/ + it works without my patch, but with it qemu hangs + oh, i thought it worked when not using continue + with my patch I can reach idt_init only using next + and without all works fine + mcsim: are you sure you correctly built it with debugging symbols + ? + I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0 + hm + i have internal kvm errors actually + mcsim: do you use kvm ? + mcsim: and why break on those functions ? + i'm not sure the address space is already fine at this point + no. I don't have hardware virtualisation support. + hm actually, you won't be able to use gdb + i just remembered how gnumach is linked and mapped :/ + the addresses in the elf image are low addresses, matching the + image as it is loaded by the boot loader + I was wondering why qemu hangs. + then the kernel uses segmentation to map itself at 2 (or 3 + previously) GiB + well, if the addresses are wrong, your breakpoints are wrong + i even wonder how it can work when stepping + i don't have the issue with x15 because of its linker script + Are there any ways of such debugging without qemu? + i don't think so + as antrik told you, the in kernel debugger needs many services + running before being usable + you'll have to use printf, and there may be steps during bootstrap + when even that isn't available + So I need computer with hardware virtualisation? + well, of course stepping works, since the breakpoints are relative + no + kvm has nothing to do with the problem + it's just that the problem appears differently with kvm enabled + ok. thank you. + good luck + braunr: would it be hard to "fix" gnumach to avoid the + segmentation magic?... + antrik: because of the linux drivers, it may + or alternatively, implement something in GDB to deal with that?... + antrik: i didn't study that part enough to know for sure + uhm... why would the Linux drivers depend on that? does Linux also + do such magic?... + well it should simply be a matter of shifting the address by a + fixed offset + antrik: linux drivers rely on physical memory being allocated + through kmalloc + so there must be a direct mapping between virtual kernel memory + and physical memory + they don't specifically need that segmentation settings + so if you remove the offset implemented through segmentation, you + have to replace it with page mapping + and i don't know how much needs to be done for that + you also need to link the kernel differently + hm, OK + so adding GDB support for the offset would probably be easier... + yes + but using the offset must only be done once segmentation is set up + so you must break after gdt_init + not on it + mcsim: why do you break on these functions btw ? + I just wanted to find out why qemu hangs + yes but why those ? + I found out that before gdt_init all workes fine, but after qemu + hangs. So idt_init is just the next function + ok + and does your patch change something to how segmentation is + initialized ? + now + no + try to build it with the regular cflags + i don't know if gnumach can work with -O0 + I've tried. But all the same + Regular are -g -O2 + can you make your patch available ? + yes + it is available in gnumach repository at savannah + tree mplaneta/libbraunr/master + well, if the segmentation stuff is the thing GDB has problems + with, I don't see how it can work without your patch... + without ? + well, the patch shouldn't affect the segmentation... so I don't + see how it can make a difference + he said qemu hanged + so let's not introduce gdb yet + qemu can hang for other reasons + oh, right, without GDB... + 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 + + youpi: in ipc/ipc_hash.c, there is code which computes the size of + the global (space, port)->entry hash table + youpi: you may be interested in tuning this one too + I know + ok + the current value is not so bad + it's big enough for buildds to run fine + 256 if i'm right + well + it won't fail + we're limited by the 4000 object limitation anyway + since it's a chained hash table + but increasing it may help performances a bit + 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 + + jkoenig: why does gnumach appear as "root=device:hd0s1" in ps ? + braunr, it's the closest we can do to its command line + doesn't it deserve something special like kernel threads in linux + ? + so that it's actually clear that it's a special task/process + you mean something like [mach root=device:hd0s1] ? + something like that yes + 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 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: 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 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: 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 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: mcsim: i also said i was wrong about that zone_gc is the only one -2011-04-19 + +# IRC, freenode, #hurd, 2011-04-19 antrik: mcsim: i added back a new per-cpu layer as planned @@ -649,7 +655,8 @@ IRC, freenode, #hurd, 2011-04-12: loops, just as in zone_gc, to reduce contention and avoid deadlocks this is really common in memory allocators -2011-04-23 + +# IRC, freenode, #hurd, 2011-04-23 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: 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 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: 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 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: 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 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: there is work to be done ;) (not to mention the obvious about replacing all the calls to the zone allocator, and testing/debugging afterwards) + + +# IRC, freenode, #hurd, 2011-07-14 + + can you make your patch available ? + it is available in gnumach repository at savannah + tree mplaneta/libbraunr/master + mcsim: i'll test your branch + ok. I'll give you a link in a minute + hm why balloc ? + Braun's allocator + err + + http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=kern/kmem.c;h=37173fa0b48fc9d7e177bf93de531819210159ab;hb=HEAD + mcsim: this is the interface i had in mind for a kernel version :) + very similar to the original slab allocator interface actually + well, you've been working + 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 + because in git repository there is no such file + mcsim: how do you configure the kernel before building ? + 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" + I didn't configure it. I just run dpkg-buildsource -b. + oh you build the debian package + well my version was by configure --enable-kdb --enable-rtl8139 + and it seems stuck in an infinite loop during bootstrap + and printf doesn't work. The first function called by c_boot_entry + is printf(version). + mcsim: also, you're invited to get the x15mach version of my + files, which are gplv2+ licensed + be careful of my macros.h file, it can conflict with the + macros_help.h file from gnumach iirc + There were conflicts with MACRO_BEGIN and MACRO_END. But I solved + it + ok + it's tricky + 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 + + does anyone know if posix (or mach) has requirements or a policy + about the placement of allocations of virtual space ? + a policy such as bottom-up ? + or "find lowest vailable space" ? + 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) + i was wondering how e.g. libraries are linked near the stack + (possibly at slightly random addresses) + does the linker walk the address space entries top-down ? + jkoenig: i didn't see anything either in the mach interface, but i + may have missed something + jkoenig: most systems i've been studying mark the vm regions for + the heap and the stack + but for mach, the stack is just allocated virtual memory at the + top of the space + so the "placement policy" is either completely outside the kernel, + or relies on its interface + 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 + jkoenig: threads have their own stacks, under the responsibility + of the user trhead implementation + but a program usually needs a stack even before it runs + i had to set one to bootstrap modules in v0.1 + but i wonder if it's just for bootstrapping (and then propagated + by fork()) or part of the interface + but this doesn't matter much actually, the allocation mechanism i + have in mind can actually support multiple policies + 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) + i think so + i'll have a look at the exec server + jkoenig: did the previous implementation of procfs show task maps + ? + braunr, I don't think so, I would probably have felt compelled to + include them in the new one if it did :-) + hmmm + we definitely need that + is there a compelling use case you think about in particular? + yes + i failed to understand how gnumach behaved wrt ipc right spaces + +[[rework_gnumach_ipc_spaces]] + + and when i did, i found out my work was impossible to integrate + "ipc right spaces" ? + each task have an ipc space, which contains righs + rights + the ipc translation layer converts space/name and space/port + tuples to rights + 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 + i don't want to make this kind of mistake again, so i'd like a + clear and detailed view of the vm spaces + (it's only compelling for myself, all right) + but + we have vminfo + rbraun@nordrassil:~$ vminfo $$ | wc -l + 1046 + oh my + in comparison, a firefox instance has less than 500 on linux + 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?) + jkoenig: sorry for being confusing, it's not that at all + (btw feel free to tell me to just go read the source or whatever) + jkoenig: don't worry + braunr, no problem + 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 + 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 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 youpi: is there any use of the port renaming facility ? I don't know @@ -250,7 +254,8 @@ IRC, freenode, #hurd, 2011-04-23 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 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 antrik: a data structure used to map integers to pointers http://fxr.watson.org/fxr/source/lib/idr.c?v=linux-2.6 -2011-06-18 + +# IRC, freenode, #hurd, 2011-06-08 + + hm, reverse space/port to name lookups also suck + having separate types for simple ipc entries and splay tree + entries really makes many parts of the ipc code complicated + and a global hash table for these operations is scary + + +# IRC, freenode, #hurd, 2011-06-09 + + hm nice, my radix tree code runs inside gnumach, along with the + original splay tree code and assertions making sure results are the same + there is this "collision" thing i'm not sure to understand but + once this is solved, replacing the splay trees should be easy + + youpi: is there a way to easily know the number of send rights + associated to a port ? + portinfo ? + portinfo gives information in a space + but this is specific to a port + is there an option for that ? + -v + hm ok + 25: send (refs: 550) + nice + youpi: if you have time, could you give me the min/max/avg numbers + of send rights referring to the same port on buildds ? + 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 + the latter seems better but there could be unexpected cases on + machines using large amounts of resources like the buildds + max is 64k + min is 1 of course :) + 64k + then it's not what i'm looking for + avg is 55 + isn't this the number of urefs ? + I don't know + hmm + what i'm looking for is the number of *pure send rights* for the + same port + i don't think portinfo can give it + there can only be one such send right per task for the same port + 64k would mean there are 64k tasks + ok, so it's more difficult + it means using -t + ahh + and run n^2 portinfo over the n processes + i see + Mmm, that will however still show any duplicate send right + but then by min/max/avg, you mean, over time ? + i'll change the source code, simpler + e.g. min would be right after boot? + min is 1 + 1 what ? + 1 send right to a port + ah, 1 for a given port + yes + ok, it becomes really hairy to compute, I don't hav ethe time :) + avg and max are more interesting :) + no worries + braunr: I wouldn't be surprised that max is the number of tasks + e.g. for a send port to the proc server for instance + youpi: it is, but i'm not looking for potential numbers + I'm not talking about a potential number, but an actual number + that's almost always true + for one port, yes + but yes, ok for max + this makes choosing an appropriate data structure difficult + + braunr: actually, min number of send rights to a port is 0... but + I'm sure you know that already :-) + + youpi: normally each client gets a separate port. I'm not sure + there are any ports with send rights distributed over many tasks... + + antrik, what about / ? + + antrik: not necessarily + + jkoenig: not sure... isn't the "/" port authenticated to the + specific user? + + antrik, I guess so, but a single user could still have many + tasks. + (wrt /) + 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 + at least I don't think so + tasks are authenticated, not users + err... GIDs :-) + 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? + hmm "rpctrace ls -d /" does not show any authentication calls, + only a lookup("") on the root which returns a different port + so I guess the root port is "deauthenticated" or something when + the uid of a process is changed. + too bad cfhammer isn't around, he digged into all this stuff... + I know that there is a mechanism which reauths all FDs when the + IDs of a process change + but I'm not sure the "/" port uses this mechanism + + 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 + + antrik: and yes, min number is 0, but in that case you don't need + (space, port) -> right lookups :) + antrik: or put in another way, whichever reasonable structure you + use, when it's empty, you don't care much + which also means that the min number has actually no value here + because the same applies to 1 + + then what seems to take most time is forks + and i hope my upcoming kernel changes will help the situation a + bit + what are your incoming gnumach changes about? + the ipc translation layer speed + which basically means operating on port names (looking them up, + inserting, removing, renaming, looking up send rights to a specific + ports) will be faster + and i believe forks are (one of) the most demanding use cases wrt + ipc space manipulation + i'm really surprised how badly the splay trees are used + the worst case for this data structure is traversal + and this is done in many situations + leaving the tree in its worst case shape + and i didn't mentioned the bunch of memory writes occurring, event + for things like lookups or traversals + this is slow and can disrupt many cpu cache lines + 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 + a simple traversal_next involves a rotation *gasp* + this means potentially writing on 3 different cache lines, for + *one* next operation + what are you replacing that splay tree with? + radix trees + much shorter paths + extremely few memory writes + locality of reference when traversing + good cache usage (as many of the top nodes are reused) + the two drawbacks are 1/ memory allocation for external nodes, + which means the tree must be preloaded before locking + and 2/ high memory overhead if the keys are sparse + but this isn't the case with port names, unless someone messes it + up by assigning random names to many rights + + braunr: so, when will we see the first performance comparision? + :-) + antrik: that's a topic of itself, how to compare ? + antrik: the thing is, my current gnumach patches only makes + assertions + this is the best way i found to test my tree in real life + conditions + much cleanup is needed + and what i'd like to do is to completely replace all teh + translation layer structures with it + which means removing much code, making sure it still works as + expected + this is tedious + so one month at least + 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 + rough estimates are easy, yes + but my observations my be wrong :p + braunr: well, we don't really need precise numbers... + unless you need to do some kind of fine-tuning? + 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 is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port? there is a way @@ -52,3 +55,32 @@ License|/fdl]]."]]"""]] which combines file and directory operations of course, files and directories implement those functions differently marcusb: do you know why this behavior (cat on directories) was changed? + + +# IRC, freenode, #hurd, 2011-07-13 + +A related issue: + + rbraun@nordrassil:~$ vminfo $$ | wc -l + 1039 + any idea why a shell would consume more than 1039 map entries ? + (well, not more actually) + even the kernel and ext2fs have around 100 + (the kernel has actually only 23, which is very good and expected) + 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. + tschwinge: this would require naming objects at the mach level + e.g. when creating an object + giving it the path of a file for example + 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? + braunr: For example, yes. + what ? + ?! + braunr: + http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00097.html + 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 + + Another thing: the lsattr and chattr programs seems to be bogus + on Hurd. Are they present since they are part of e2fsprogs? + I don't think the Hurd has an interface for it + 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]]. -- cgit v1.2.3