diff options
Diffstat (limited to 'open_issues')
26 files changed, 1400 insertions, 14 deletions
diff --git a/open_issues/active_vs_passive_symlink_translator.mdwn b/open_issues/active_vs_passive_symlink_translator.mdwn new file mode 100644 index 00000000..cbd9b077 --- /dev/null +++ b/open_issues/active_vs_passive_symlink_translator.mdwn @@ -0,0 +1,44 @@ +[[!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-07-25 + +Set an *active* (not *passive*) `/hurd/symlink` translator on a node. + + < antrik> that's strange: the file doesn't look like a symlink in ls output + -- but it behaves like one... + < antrik> using firmlink instead of symlink yields less confusing + results... + < gg0> how does it behaves like one? + < antrik> perhaps the symlink mechanism only fully works for a passive + symlink translator, not an active one + < antrik> gg0: if you access it, you actually get the linked file contents + < antrik> it's only ls that's confused + < antrik> it might be because ls -l uses O_NOFOLLOW, which results in + O_NOTRANS, so it sees the original file contents + < gg0> stat says it's still 12264 bytes + < antrik> stat also seems to use NOFOLLOW + < antrik> wc will show the "correct" size + < gg0> ok + < antrik> if you set it as passive translator, it works as expected... but + then you better don't forget removing it, as it won't go away after a + reboot :-) + < antrik> but as I said, you can just ignore the weirdness -- or use + firmlink instead + < antrik> the thing is, if symlink is set as a passive translator, the + filesystem handles it specially, so it really looks like a symlink to + programs using NOFOLLOW. that's not the case with an active symlink... so + programs using NOFOLLOW simply do not see the active symlink at all + < antrik> firmlink OTOH ignores NOFOLLOW, so you always see the linked-to + file + + * [[hurd/translator/short-circuiting]] diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index bba0d171..c06edc9b 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -12,8 +12,30 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_gnumach]] -Missing clock_gettime(CLOCK_MONOTONIC) (e.g. for iceweasel) +Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel) -It could be a mere matter of extending the mappable clock: add it to mapped_time_value_t in gnumach, handle it in gnumach/kern/mach_clock.c, and make clock_gettime use it. +It could be a mere matter of extending the mappable clock: add it to +`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and +make `clock_gettime` use it. -BTW, also make gettimeofday() use it, since it's way more efficient and some applications assume that it is. +BTW, also make `gettimeofday()` use it, since it's way more efficient and some +applications assume that it is. + +What about adding a nanosecond-precision clock, too? --[[tschwinge]] + +IRC, freenode, #hurd, 2011-08-26: + + < pinotree> youpi: thing is: apparently i found a simple way to have a + monotonic clock as mmap-able device inside gnumach + < pinotree> currently, in kern/mach_clock.c there's a variable 'time', + which gets increased on clock interrupt, and optionally modified by + host_set_time + < pinotree> () + < pinotree> if i add a new variable next to it, only increasing it on + interrupt but not modifying it at all otherwise, would that give me a + monotonic clock? + < pinotree> at least on sme basic tests i did, it seems it could work that + way + < youpi> yes, it should work + < braunr> sure + < youpi> and that's the way I was considering implementing it diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn index ab90a6b6..552cd2c9 100644 --- a/open_issues/code_analysis.mdwn +++ b/open_issues/code_analysis.mdwn @@ -27,6 +27,13 @@ analysis|performance]], [[formal_verification]], as well as general * [[!wikipedia List_of_tools_for_static_code_analysis]] + * [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/) + + For example, [Debian's hurd_20110319-2 + package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html) + (Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious; + the realloc issues are for real*). + * Coccinelle * <http://lwn.net/Articles/315686/> diff --git a/open_issues/glibc_init_first.mdwn b/open_issues/glibc_init_first.mdwn new file mode 100644 index 00000000..774b7828 --- /dev/null +++ b/open_issues/glibc_init_first.mdwn @@ -0,0 +1,78 @@ +[[!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_glibc]] + +IRC, freenode, #hurd, 2011-07-22 + + [additional init-first.c patch] + < tschwinge> civodul: The only thing I wonder about: Roland also once had + done similar changes, which I then found they didn'T work with GCC 4.1, + and backed them out in 08f53ee9d265ffdc7e0affd6acf346cceeb65559 and fixed + the issue differently in d8d27e633a7860b37fd2e3142822b640a066cc0f (and + e17cef66140d4c97710ea88bd8d12612799e1e0f). Have you reviewed this? + < tschwinge> That's in the Savannah glibc repository. + < tschwinge> And this has been in 2007, four years ago. I don't remember + all the details. + < tschwinge> And here is quite a good summary of this stuff, from + init-first.c: + < tschwinge> /* XXX This is all a crock and I am not happy with it. + < tschwinge> This poorly-named function is called by static-start.S, + < civodul> braunr: thanks; i must admit it took me a while to figure it out + ;-) + < tschwinge> which should not exist at all. */ + < tschwinge> civodul: I can imagine... :-/ + < civodul> tschwinge: re Roland's changes, that's weird; i plan to try to + reinstate his change and see if it works + < civodul> now, i won't test with GCC 4.1... + < tschwinge> Yeah... + < tschwinge> I'm happy if it works with 4.4 onwards. + < tschwinge> civodul: And it's safe (in GCC terms) to write to ``* ((void + **) __builtin_frame_address (0) + 1)'', and similar? + < tschwinge> Or should we be coding this few stuff in assembly? + < civodul> tschwinge: well, we should add a compile-time assertion for + __builtin_return_address (0) == *((void**)__builtin_frame_address (0) + + 1) + < civodul> (i think GCC can figure it out at compile-time) + < civodul> but on IA32 it should always be true + < civodul> what's the name of glibc's compile-time assert macro already? + < tschwinge> I wonder whether that might interfere with some of GCC's + optimizations? + < civodul> what? + < tschwinge> Well, it seems unclean for me to be modifying a function's + return address from within C code. + < tschwinge> civodul: I added a verify.h in the t/verify.h branch. But + people didn't really like it too much. They rather wanted to directly + inline the array[(cond)?1:-1] code. + < civodul> ok + < civodul> i remember a debate about Gnulib's verify.h + < civodul> i thought something comparable had landed eventually + < tschwinge> civodul: Oh, maybe I missed it. + < tschwinge> civodul: In init-first.c:init, what about the usage of + data[-1] in the else path (not using cthreads) -- is that good as-is? + < civodul> tschwinge: oooh, it probably needs to fixed too + < civodul> but i haven't reached that point yet ;-) + * civodul tries to cross-bootstrap GNU from scratch + < tschwinge> civodul: I'd be happy to learn what was wrong with Roland's + original idea of fixing this. Or perhaps this was a GCC 4.1 bug? Or + perhaps GCC was inlining to much, and then got confused with frames and + return addresses? + < civodul> tschwinge: Roland's change looks good to me, so it could have + been a GCC bug + < civodul> tschwinge: OK to commit the patch to t/init-first.c (with both + data[-1] replaced)? + < tschwinge> civodul: OK, if you are confident that it works with GCC 4.4 + onwards. If yes, please add your changelog snippet to .topmsg, and also + add a not that Roland's original code may in fact have been fine, and we + may have hit a compiler bug. + < civodul> tschwinge: OK, will do + < civodul> tschwinge: though regarding Roland's change, i'd prefer to + actually test and see + < tschwinge> civodul: Thanks! diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index 448aafcc..a728fc9d 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -923,3 +923,400 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. <braunr> 20 years ago <braunr> but it's a source of deadlock <mcsim> Indeed. I'll won't use kmem_alloc_pageable. + + +# IRC, freenode, #hurd, 2011-08-09 + + < braunr> mcsim: what's the "bug related to MEM_CF_VERIFY" you refer to in + one of your commits ? + < braunr> mcsim: don't use spin_lock_t as a member of another structure + < mcsim> braunr: I confused with types in *_verify functions, so they + didn't work. Than I fixed it in the commit you mentioned. + < braunr> in gnumach, most types are actually structure pointers + < braunr> use simple_lock_data_t + < braunr> mcsim: ok + < mcsim> > use simple_lock_data_t + < mcsim> braunr: ok + < braunr> mcsim: don't make too many changes to the code base, and if + you're unsure, don't hesitate to ask + < braunr> also, i really insist you rename the allocator, as done in x15 + for example + (http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=vm/kmem.c), instead of + a name based on mine :/ + < mcsim> braunr: Ok. It was just work name. When I finish I'll rename the + allocator. + < braunr> other than that, it's nice to see progress + < braunr> although again, it would be better with some reports along + < braunr> i won't be present at the meeting tomorrow unfortunately, but you + should use those to report the status of your work + < mcsim> braunr: You've said that I have to tweak gc process. Did you mean + to call mem_gc() when physical memory ends instead of calling it every x + seconds? Or something else? + < braunr> there are multiple topics, alhtough only one that really matters + < braunr> study how zone_gc was called + < braunr> reclaiming memory should happen when there is pressure on the VM + subsystem + < braunr> but it shouldn't happen too ofte, otherwise there is trashing + < braunr> and your caches become mostly useless + < braunr> the original slab allocator uses a 15-second period after a + reclaim during which reclaiming has no effect + < braunr> this allows having a somehow stable working set for this duration + < braunr> the linux slab allocator uses 5 seconds, but has a more + complicated reclaiming mechanism + < braunr> it releases memory gradually, and from reclaimable caches only + (dentry for example) + < braunr> for x15 i intend to implement the original 15 second interval and + then perform full reclaims + < mcsim> In zalloc mem_gc is called by vm_pageout_scan, but not often than + once a second. + < mcsim> In balloc I've changed interval to once in 15 seconds. + < braunr> don't use the code as it is + < braunr> the version you've based your work on was meant for userspace + < braunr> where there isn't memory pressure + < braunr> so a timer is used to trigger reclaims at regular intervals + < braunr> it's different in a kernel + < braunr> mcsim: where did you see vm_pageout_scan call the zone gc once a + second ? + < mcsim> vm_pageout_scan calls consider_zone_gc and consider_zone_gc checks + if second is passed. + < braunr> where ? + < mcsim> Than zone_gc can be called. + < braunr> ah ok, it's in zaclloc.c then + < braunr> zalloc.c + < braunr> yes this function is fine + < mcsim> so old gc didn't consider vm pressure. Or I missed something. + < braunr> it did + < mcsim> how? + < braunr> well, it's called by the pageout daemon + < braunr> under memory pressure + < braunr> so it's fine + < mcsim> so if mem_gc is called by pageout daemon is it fine? + < braunr> it must be changed to do something similar to what + consider_zone_gc does + < mcsim> It does. mem_gc does the same work as consider_zone_gc and + zone_gc. + < braunr> good + < mcsim> so gc process is fine? + < braunr> should be + < braunr> i see mem.c only includes mem.h, which then includes other + headers + < braunr> don't do that + < braunr> always include all the headers you need where you need them + < braunr> if you need avltree.h in both mem.c and mem.h, include it in both + files + < braunr> and by the way, i recommend you use the red black tree instead of + the avl type + < braunr> (it's the same interface so it shouldn't take long) + < mcsim> As to report. If you won't be present at the meeting, I can tell + you what I have to do now. + < braunr> sure + < braunr> in addition, use GPLv2 as the license, teh BSD one is meant for + the userspace version only + < braunr> GPLv2+ actually + < braunr> hm you don't need list.c + < braunr> it would only add dead code + < braunr> "Zone for dynamical allocator", don't mix terms + < braunr> this comment refers to a vm_map, so call it a map + < mcsim> 1. Change constructor for kentry_alloc_cache. + < mcsim> 2. Make measurements. + < mcsim> + + < mcsim> 3. Use simple_lock_data_t + < mcsim> 4. Replace license + < braunr> kentry_alloc_cache <= what is that ? + < braunr> cache for kernel map entries in vm_map ? + < braunr> the comment for mem_cpu_pool_get doesn't apply in gnumach, as + there is no kernel preemption + < braunr> "Don't attempt mem GC more frequently than hz/MEM_GC_INTERVAL + times a second. + < braunr> " + < mcsim> sorry. I meant vm_map_kentry_cache + < braunr> hm nothing actually about this comment + < braunr> mcsim: ok + < braunr> yes kernel map entries need special handling + < braunr> i don't know how it's done in gnumach though + < braunr> static preallocation ? + < mcsim> yes + < braunr> that's ugly :p + < mcsim> but it uses dynamic allocation further even for vm_map kernel + entries + < braunr> although such bootstrapping issues are generally difficult to + solve elegantly + < braunr> ah + < mcsim> now I use only static allocation, but I'll add dynamic allocation + too + < braunr> when you have time, mind the coding style (convert everything to + gnumach style, which mostly implies using tabs instead of 4-spaces + indentation) + < braunr> when you'll work on dynamic allocation for the kernel map + entries, you may want to review how it's done in x15 + < braunr> the mem_source type was originally intended for that purpose, but + has slightly changed once the allocator was adapted to work in my kernel + < mcsim> ok + < braunr> vm_map_kentry_zone is the only zone created with ZONE_FIXED + < braunr> and it is zcram()'ed immediately after + < braunr> so you can consider it a statically allocated zone + < braunr> in x15 i use another strategy: there is a special kernel submap + named kentry_map which contains only one map entry (statically allocated) + < braunr> this map is the backend (mem_source) for the kentry_cache + < braunr> the kentry_cache is created with a special flag that tells it + memory can't be reclaimed + < braunr> when the cache needs to grow, the single map entry is extended to + cover the allocated memory + < braunr> it's similar to the way pmap_growkernel() works for kernel page + table pages + < braunr> (and is actually based on that idea) + < braunr> it's a compromise between full static and dynamic allocation + types + < braunr> the advantage is that the allocator code can be used (so there is + no need for a special allocator like in netbsd) + < braunr> the drawback is that some resources can never be returned to + their source (and under peaks, the amount of unfreeable resources could + become large, but this is unexpected) + < braunr> mcsim: for now you shouldn't waste your time with this + < braunr> i see the number of kernel map entries is fixed at 256 + < braunr> and i've never seen the kernel use more than around 30 entries + < mcsim> Do you think that I have to left this problem to the end? + < braunr> yes + + +# IRC, freenode, #hurd, 2011-08-11 + + < mcsim> braunr: Hello. Can you give me an advice how can I make + measurements better? + < braunr> mcsim: what kind of measurements + < mcsim> braunr: How much is your allocator better than zalloc. + < braunr> slightly :p + < braunr> that's why i never took the time to put it in gnumach + < mcsim> braunr: Just I thought that there are some rules or + recommendations of such measurements. Or I can do them any way I want? + < braunr> mcsim: i don't know + < braunr> mcsim: benchmarking is an art of its own, and i don't even know + how to use the bits of profiling code available in gnumach (if it still + works) + < antrik> mcsim: hm... are you saying you already have a running system + with slab allocator?... :-) + < braunr> mcsim: the main advantage i can see is the removal of many + arbitrary hard limits + < mcsim> antrik: yes + < antrik> \o/ + < antrik> nice work! + < braunr> :) + < braunr> the cpu layer should also help a bit, but it's hard to measure + < braunr> i guess it could be seen on the ipc path for very small buffers + < mcsim> antrik: Thanks. But I still have to 1. Change constructor for + kentry_alloc_cache. and 2. Make measurements. + < braunr> and polish the whole thing :p + < antrik> mcsim: I'm not sure this can be measured... the performance + differente in any real live usage is probably just a few percent at most + -- it's hard to construct a benchmark giving enough precision so it's not + drowned in noise... + < antrik> perhaps it conserves some memory -- but that too would be hard to + measure I fear + < braunr> yes + < braunr> there *should* be better allocation times, less fragmentation, + better accounting ... :) + < braunr> and no arbitrary limits ! + < antrik> :-) + < braunr> oh, and the self debugging features can be nice too + < mcsim> But I need to prove that my work wasn't useless + < braunr> well it wasn't, but that's hard to measure + < braunr> it's easy to prove though, since there are additional features + that weren't present in the zone allocator + < mcsim> Ok. If there are some profiling features in gnumach can you give + me a link with their description? + < braunr> mcsim: sorry, no + < braunr> mcsim: you could still write the basic loop test, which counts + the number of allocations performed in a fixed time interval + < braunr> but as it doesn't match many real life patterns, it won't be very + useful + < braunr> and i'm afraid that if you consider real life patterns, you'll + see how negligeable the improvement can be compared to other operations + such as memory copies or I/O (ouch) + < mcsim> Do network drivers use this allocator? + < mcsim> ok. I'll scrape up some test and than I'll report results. + + +# IRC, freenode, #hurd, 2011-08-26 + + < mcsim> hello. Are there any analogs of copy_to_user and copy_from_user in + linux for gnumach? + < mcsim> Or how can I determine memory map if I know address? I need this + for vm_map_copyin + < guillem> mcsim: vm_map_lookup_entry? + < mcsim> guillem: but I need to transmit map to this function and it will + return an entry which contains specified address. + < mcsim> And I don't know what map have I transmit. + < mcsim> I need to transfer static array from kernel to user. What map + contains static data? + < antrik> mcsim: Mach doesn't have copy_{from,to}_user -- instead, large + chunks of data are transferred as out-of-line data in IPC messages + (i.e. using VM magic) + < mcsim> antrik: can you give me an example? I just found using + vm_map_copyin in host_zone_info. + < antrik> no idea what vm_map_copyin is to be honest... + + +# IRC, freenode, #hurd, 2011-08-27 + + < braunr> mcsim: the primitives are named copyin/copyout, and they are used + for messages with inline data + < braunr> or copyinmsg/copyoutmsg + < braunr> vm_map_copyin/out should be used for chunks larger than a page + (or roughly a page) + < braunr> also, when writing to a task space, see which is better suited: + vm_map_copyout or vm_map_copy_overwrite + < mcsim> braunr: and what will be src_map for vm_map_copyin/out? + < braunr> the caller map + < braunr> which you can get with current_map() iirc + < mcsim> braunr: thank you + < braunr> be careful not to leak anything in the transferred buffers + < braunr> memset() to 0 if in doubt + < mcsim> braunr:ok + < braunr> antrik: vm_map_copyin() is roughly vm_read() + < antrik> braunr: what is it used for? + < braunr> antrik: 01:11 < antrik> mcsim: Mach doesn't have + copy_{from,to}_user -- instead, large chunks of data are transferred as + out-of-line data in IPC messages (i.e. using VM magic) + < braunr> antrik: that "VM magic" is partly implemented using vm_map_copy* + functions + < antrik> braunr: oh, you mean it doesn't actually copy data, but only page + table entries? if so, that's *not* really comparable to + copy_{from,to}_user()... + + +# IRC, freenode, #hurd, 2011-08-28 + + < braunr> antrik: the equivalent of copy_{from,to}_user are + copy{in,out}{,msg} + < braunr> antrik: but when the data size is about a page or more, it's + better not to copy, of course + < antrik> braunr: it's actually not clear at all that it's really better to + do VM magic than to copy... + + +# IRC, freenode, #hurd, 2011-08-29 + + < braunr> antrik: at least, that used to be the general idea, and with a + simpler VM i suspect it's still true + < braunr> mcsim: did you progress on your host_zone_info replacement ? + < braunr> mcsim: i think you should stick to what the original + implementation did + < braunr> which is making an inline copy if caller provided enough space, + using kmem_alloc_pageable otherwise + < braunr> specify ipc_kernel_map if using kmem_alloc_pageable + < mcsim> braunr: yes. And it works. But I use kmem_alloc, not pageable. Is + it worse? + < mcsim> braunr: host_zone_info replacement is pushed to savannah + repository. + < braunr> mcsim: i'll have a look + < mcsim> braunr: I've pushed one more commit just now, which has attitude + to host_zone_info. + < braunr> mem_alloc_early_init should be renamed mem_bootstrap + < mcsim> ok + < braunr> mcsim: i don't understand your call to kmem_free + < mcsim> braunr: It shouldn't be there? + < braunr> why should it be there ? + < braunr> you're freeing what the copy object references + < braunr> it's strange that it even works + < braunr> also, you shouldn't pass infop directly as the copy object + < braunr> i guess you get a warning for that + < braunr> do what the original code does: use an intermediate copy object + and a cast + < mcsim> ok + < braunr> another error (without consequence but still, you should mind it) + < braunr> simple_lock(&mem_cache_list_lock); + < braunr> [...] + < braunr> kr = kmem_alloc(ipc_kernel_map, &info, info_size); + < braunr> you can't hold simple locks while allocating memory + < braunr> read how the original implementation works around this + < mcsim> ok + < braunr> i guess host_zone_info assumes the zone list doesn't change much + while unlocked + < braunr> or that's it's rather unimportant since it's for debugging + < braunr> a strict snapshot isn't required + < braunr> list_for_each_entry(&mem_cache_list, cache, node) max_caches++; + < braunr> you should really use two separate lines for readability + < braunr> also, instead of counting each time, you could just maintain a + global counter + < braunr> mcsim: use strncpy instead of strcpy for the cache names + < braunr> not to avoid overflow but rather to clear the unused bytes at the + end of the buffer + < braunr> mcsim: about kmem_alloc vs kmem_alloc_pageable, it's a minor + issue + < braunr> you're handing off debugging data to a userspace application + < braunr> a rather dull reporting tool in most cases, which doesn't require + wired down memory + < braunr> so in order to better use available memory, pageable memory + should be used + < braunr> in the future i guess it could become a not-so-minor issue though + < mcsim> ok. I'll fix it + < braunr> mcsim: have you tried to run the kernel with MC_VERIFY always on + ? + < braunr> MEM_CF_VERIFY actually + < mcsim1> yes. + < braunr> oh + < braunr> nothing wrong + < braunr> ? + < mcsim1> it is always set + < braunr> ok + < braunr> ah, you set it in macros.h .. + < braunr> don't + < braunr> put it in mem.c if you want, or better, make it a compile-time + option + < braunr> macros.h is a tiny macro library, it shouldn't define such + unrelated options + < mcsim1> ok. + < braunr> mcsim1: did you try fault injection to make sure the checking + code actually works and how it behaves when an error occurs ? + < mcsim1> I think that when I finish I'll merge files cpu.h and macros.h + with mem.c + < braunr> yes that would simplify things + < mcsim1> Yes. When I confused with types mem_buf_fill worked wrong and + panic occurred. + < braunr> very good + < braunr> have you progressed concerning the measurements you wanted to do + ? + < mcsim1> not much. + < braunr> ok + < mcsim1> I think they will be ready in a few days. + < antrik> what measurements are these? + < mcsim1> braunr: What maximal size for static data and stack in kernel? + < braunr> what do you mean ? + < braunr> kernel stacks are one page if i'm right + < braunr> static data (rodata+data+bss) are limited by grub bugs only :) + < mcsim1> braunr: probably they are present, because when I created too big + array I couldn't boot kernel + < braunr> local variable or static ? + < mcsim1> static + < braunr> how large ? + < mcsim1> 4Mb + < braunr> hm + < braunr> it's not a grub bug then + < braunr> i was able to embed as much as 32 MiB in x15 while doing this + kind of tests + < braunr> I guess it's the gnu mach boot code which only preallocates one + page for the initial kernel mapping + < braunr> one PTP (page table page) maps 4 MiB + < braunr> (x15 does this completely dynamically, unlike mach or even + current BSDs) + < mcsim1> antrik: First I want to measure time of each cache + creation/allocation/deallocation and then compile kernel. + < braunr> cache creation is irrelevant + < braunr> because of the cpu pools in the new allocator, you should test at + least two different allocation patterns + < braunr> one with quick allocs/frees + < braunr> the other with large numbers of allocs then their matching frees + < braunr> (larger being at least 100) + < braunr> i'd say the cpu pool layer is the real advantage over the + previous zone allocator + < braunr> (from a performance perspective) + < mcsim1> But there is only one cpu + < braunr> it doesn't matter + < braunr> it's stil a very effective cache + < braunr> in addition to reducing contention + < braunr> compare mem_cpu_pool_pop() against mem_cache_alloc_from_slab() + < braunr> mcsim1: work is needed to polish the whole thing, but getting it + actually working is a nice achievement for someone new on the project + < braunr> i hope it helped you learn about memory allocation, virtual + memory, gnu mach and the hurd in general :) + < antrik> indeed :-) diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn new file mode 100644 index 00000000..5c7031c9 --- /dev/null +++ b/open_issues/hurd_101.mdwn @@ -0,0 +1,38 @@ +[[!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]]."]]"""]] + +(See Wikipedia page for the meaning of [[!wikipedia "101_(term)"]].) + +Not the first time that something like this is proposed... + +IRC, freenode, #hurd, 2011-07-25 + + [failed GNU/Hurd project] + < antrik> gnu_srs1: I wouldn't say he was on track. just one of the many + many people who insist on picking a hard task; realizing that indeed it's + hard; and going into hiding + < antrik> we see that happen every couple of months + < cluck> maybe we need a "hurd 101" + < cluck> getting a teacher and setting up a regularly held "class" for hurd + noobs + < Tekk_> cluck: what would that include? + < cluck> explaining core concepts, giving out "homework" (small tasks), etc + < cluck> that way "the big guys" could focus on the hard stuff and have an + army of code monkeys at their disposal to write speced stuff + < cluck> (then again this idea would heavily depend on available "teachers" + and "students", which, going by gsoc numbers, may not be all that + helpful) + < Tekk_> cluck: gsoc isn't an accurate indicator + < Tekk_> cluck: I'm not allowed to participate in gsoc but I'd join :P + < antrik> cluck: we don't need code monkeys... we need hackers + < Tekk_`> antrik: code monkeys involve into hackers + < Tekk_`> under the right conditions + < cluck> antrik: jokes aside some sort of triage system/training ground for + newcomers could be helpful diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index 0d3628ec..fb665c67 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -40,8 +40,36 @@ IRC, OFTC, #debian-hurd, 2011-07-21. The fix thus being: link the main application with -lpthread. -The same symptom appears in an odd case, for instance: +IRC, freenode, #hurd, 2011-08-17 + + < youpi> i.e. openjade apparently dlopen()s modules which use pthreads, but + openjade itself is not liked against libpthread + < youpi> which means unexpectedly loading pthreads on the fly, which is + not implemented + < youpi> (and hard to implement of course) + < youpi> gnu_srs: so simply tell openjade people to link it with -lpthread + < gnu_srs> Shuoldn't missing linking with pthread create an error when + building openjade then? + < youpi> no + < youpi> because it's just a module which needs pthread + < youpi> and that module _is_ linked with -lpthread + < youpi> and dlopen() loads libpthreads too due to that + < youpi> but that's unexpected, for the libpthread initialization stuff + < youpi> (and too late to fix initlaization) + < gnu_srs> How come that other OSes build opensp w/o problems? + < youpi> because there are stubs in the libc + < gnu_srs> Sorry for the delay: What hinders stubs to be present also in + the Hurd libc parts too, to cope with this problem? + < youpi> doing it + < youpi> which is hard because you need libpthread bits inside the libc + < youpi> making it simpler would need building libpthread at the same time + as libc + +[[packaging_libpthread]] +--- + +The same symptom appears in an odd case, for instance: buildd@hurd:~$ ldd /usr/bin/openjade libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) diff --git a/open_issues/mach_tasks_memory_usage.mdwn b/open_issues/mach_tasks_memory_usage.mdwn index 88e3afb8..9abb7639 100644 --- a/open_issues/mach_tasks_memory_usage.mdwn +++ b/open_issues/mach_tasks_memory_usage.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] -IRC, #hurd, 2011-01-06. +IRC, freenode, #hurd, 2011-01-06 <antrik> hm, odd... vmstat tells me that ~500 MiB of RAM are in use; but the sum of all RSS is <300 MiB... what's the rest? @@ -98,3 +98,50 @@ IRC, #hurd, 2011-01-06. <kilobug> braunr: yeah for bootstrapping issues, makes sense <braunr> it may also depends on the pic/pie options used when building libraries + + +IRC, freenode, #hurd, 2011-07-24 + + < braunr> the panic is probably due to memory shortage + < braunr> so as antrik suggested, use more swap + < antrik> gg0: you could run "vmstat 1" in another terminal to watch memory + usage + < antrik> that way we will know for sure whether it's related + < braunr> antrik: it's trickier than that + < braunr> it depends if the zones used are pageable + < antrik> braunr: well, if it's a zone map exhaustion, then the swap size + won't change anything?... + < braunr> antrik: in this case no, but if the zone is pageable and the + pager (backing anonymous memory) refuses to create memory because it + estimates it's full (all swap space is reserved), it will fail to + < braunr> too + < braunr> but i don't think there are much pageable zones in the kernel + < antrik> yes, but in that case we can see the exhaustion in vmstat :-) + < braunr> many* + < braunr> i'm not sure + < braunr> reserved swap space doesn't mean it's used + < braunr> that's one of the major changes in freebsd 4 or 5 i was + mentioning + < antrik> if it's reserved, it wouldn't show up as "free", would it?... + < braunr> (btw, it's also what makes anonymous memory merging so hard) + < braunr> yes it would + < braunr> well, it could, i'm not sure + < braunr> anonymous memory is considered as a file + < braunr> one big file filled with zeroes, which is the swap partition + < braunr> when you allocate pageable anonymous memory, a part of this + "file" is reserved + < braunr> but i don't know if the reported number if the reserved + (allocated) space, or used (actually containing data) + < braunr> is* + < braunr> i also suspect wired allocations can fail because of a full swap + (because the kernel is unable to make free pages) + < braunr> in this case vmstat will show it + < antrik> what does it matter whether there is data there or not? if it's + reserved, it's not free. if it behaves differently, I'd consider that a + serious bug + < braunr> maybe the original developers intended to monitor its actual + usage + < braunr> antrik: i've just checked how the free count gets updated, and it + looks like it is on both seqnos_memory_object_data_initialize and + seqnos_memory_object_data_write + < braunr> antrik: so i guess reserved memory is accounted for diff --git a/open_issues/mmap_crash_etc.mdwn b/open_issues/mmap_crash_etc.mdwn new file mode 100644 index 00000000..4946a5a0 --- /dev/null +++ b/open_issues/mmap_crash_etc.mdwn @@ -0,0 +1,95 @@ +[[!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]]."]]"""]] + +Several issues here: + + * [[!tag open_issue_glibc open_issue_gnumach]] Even invalid `mmap` shoudn't + crash the process. + + * [[!tag open_issue_documentation]] The memory layout example should be + documented. + + * [[!tag open_issue_gnumach]] New `vm_map` allocation strategy may be + desirable; see also [[placement_of_virtual_memory_regions]]. + + * [[!tag open_issue_glibc]] *task X deallocating an invalid port Y, most + probably a bug*. + +IRC, freenode, #hurd, 2011-08-11 + + < zyg> oh, mmap sigsegvs, strange. + < braunr> hwo do you see that ? + < zyg> braunr: I'll try to paste a minimal case + < braunr> zyg: make sure you have a sane memory setup + < braunr> 512 RAM / 1G swap seems good + < braunr> have more swap than RAM + < zyg> I have those. Still it shouldn't sigsegv. + < braunr> gnumach is picky about that + < braunr> and yes, the hurd shouldn't have bugs + < zyg> braunr: ready to crash? #include <stdio.h> #include <sys/mman.h> int + main (int argc, char **argv) { mmap(0x10000, 0x8000, PROT_READ, MAP_ANON + | MAP_FIXED, -1, 0); return 0; } + < braunr> a fixed mapping at such an address is likely to fail, yes + < braunr> but a crash, hm + < zyg> why should it fail? + < braunr> because the hurd doesn't have a common text data bss heap stack + layout + < braunr> e.g. there are mappings below text, as show by vminfo : + < braunr> $ vminfo $$ + < braunr> 0[0x1000] (prot=0) + < braunr> 0x1000[0x21000] (prot=RX, max_prot=RWX, mem_obj=105) + < braunr> 0x22000[0x1000] (prot=R, max_prot=RWX, mem_obj=105) + < braunr> 0x23000[0x1000] (prot=RW, max_prot=RWX, mem_obj=105) + < braunr> 0x24000[0x1000] (prot=0, max_prot=RWX) + < braunr> 0x25000[0xfff000] (prot=RWX, mem_obj=106) + < braunr> 0x1024000[0x1000] (prot=RWX, mem_obj=107) + < braunr> 0x1025000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108) + < braunr> 0x1026000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108, + offs=0x1000) + < braunr> 0x1027000[0x1000] (prot=RW, max_prot=RWX, mem_obj=109) + < braunr> 0x1028000[0x2000] (prot=RW, max_prot=RWX, mem_obj=110, + offs=0x1000) + < braunr> 0x102a000[0x1000] (prot=RW, max_prot=RWX, mem_obj=111) + < braunr> (sorry for the long paste) + < zyg> oh.. my mmap falls into an occupied range? + < braunr> seems so + < zyg> thanks, that was really useful. + < braunr> MAP_FIXED isn't portable, this is clearly stated in most man + pages + < zyg> yes, implementation specific it says + < braunr> well the behaviour isn't specific, it's well defined, but the + memory layout isn't + < braunr> i personally think vm_map() should be slightly changed to include + a new flag for top-down allocations + < braunr> so that our stack and libraries are at high addresses, below the + kernel + < braunr> zyg: what kind of error do you get ? i don't get sigsegv + < zyg> I get both sigsegv and sigill depending on addr + < braunr> ok + < braunr> i get sigill with your example + < braunr> the error is the same (wrong memory access) but the behaviour + changes because of the special memory configuration + < zyg> yes.. I guess the usecase is too uncommon. Else mmap would have an + guard + < braunr> some accesses cause invalid page faults (which are sent as + segmentation faults) while other cause general protection faults (which + are sent as illegal instructions) + < braunr> (this is quite weird since the GP fault is likely because the + access targets something out of the data or code segment eh) + < zyg> braunr: that's very os-specific. Do you mean hurd behaves that way? + < braunr> gnumach + < braunr> on i386 + < braunr> the segmant configuration isn't completely flat + < braunr> segment* + < braunr> hm nice + < braunr> your small program triggers the "task X deallocating an invalid + port Y, most probably a bug." message + < zyg> where do you see that? + < braunr> on the mach console diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn index 224c0826..562ccd83 100644 --- a/open_issues/multiprocessing.mdwn +++ b/open_issues/multiprocessing.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 @@ -8,7 +8,7 @@ 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_hurd]] +[[!tag open_issue_documentation open_issue_hurd]] We would expect that fine-grained, compartmentalized systems, that is, microkernel-based multi-server systems in particular, would be ideal candidates @@ -16,7 +16,7 @@ for applying multiprocessing. That is, however, only true from a first and inexperienced point of view: there are many difficulties. -IRC, #hurd, August / September 2010 +IRC, freenode, #hurd, August / September 2010 <marcusb> silver_hook: because multi-server systems depend on inter-process communication, and inter-process communication is many times more @@ -31,6 +31,37 @@ IRC, #hurd, August / September 2010 serious research challenges +IRC, freenode, #hurd, 2011-07-26 + + < braunr> 12:03 < CTKArcher> and does the hurd take more advantages in a + multicore architecture than linux ? + < braunr> CTKArcher: short answer: no + < CTKArcher> it's easier to imagine one server pro core than the linux + kernel divided to be executed on multiple cores + < braunr> CTKArcher: this approach is less efficient + < braunr> CTKArcher: threads carry state, both explicit and implicit (like + cache data) + < braunr> CTKArcher: switching to another core means resetting and + refetching this state + < braunr> it's expensive and there is no gain obtained by doing this + < braunr> thread migration (having a thread from a client also run in + servers when making synchronous RPC, even handling its own page faults) + was implemented in mach4 and is imo a very good thing we should have + < braunr> CTKArcher: and concerning linux, it's actually very scalable + < braunr> it's already like if all client threads run in servers (the + kernel is the servers there) + < braunr> rcu is used a lot + < braunr> thread migration already takes into account smt, cores, and numa + < braunr> it's hard to do something better + < braunr> (here, thread migration means being dispatched on another cpu) + < braunr> some systems like dragonflybsd go as far as to pin threads on one + processor for their entire lifetime + < braunr> in order to have rcu-like locking almost everywhere + < braunr> (you could argue it's less efficient since in the worst case + everything runs on the same cpu, but it's very unlikely, and in practice + most patterns are well balanced) + + debian-hurd list On Thu, Jan 02, 2003 at 05:40:00PM -0800, Thomas Bushnell, BSG wrote: diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn index 7594ae76..fa3d4312 100644 --- a/open_issues/packaging_libpthread.mdwn +++ b/open_issues/packaging_libpthread.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 @@ -15,6 +15,9 @@ IRC, #hurd, 2010-07-31 <tschwinge> My idea was to have a separate libpthread package. What do you think about that? <youpi> in the long term, that can't work with glibc <youpi> because of the thread stub stuff + +[[libpthread_dlopen]], for example. + <youpi> it's not really possible to keep synchronized <youpi> because you have to decide which package you unpack first <youpi> (when upgrading) diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn index eb9f3f8a..54f3ce39 100644 --- a/open_issues/performance.mdwn +++ b/open_issues/performance.mdwn @@ -26,3 +26,7 @@ severe performance degradation. For example, in this [[`fork` system call|/glibc/fork]]'s case. [[Unit_testing]] can be used for tracking performance regressions. + +--- + + * [[Degradation]] diff --git a/open_issues/performance/degradation.mdwn b/open_issues/performance/degradation.mdwn new file mode 100644 index 00000000..5db82e31 --- /dev/null +++ b/open_issues/performance/degradation.mdwn @@ -0,0 +1,28 @@ +[[!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="Degradation of GNU/Hurd ``system performance''"]] + +Email, *id:"87mxg2ahh8.fsf@kepler.schwinge.homeip.net"* (bug-hurd, 2011-07-25, +Thomas Schwinge) + +> Building a certain GCC configuration on a freshly booted system: 11 h. +> Remove build tree, build it again (2nd): 12 h 50 min. Huh. Remove build +> tree, reboot, build it again (1st): back to 11 h. Remove build tree, build +> it again (2nd): 12 h 40 min. Remove build tree, build it again (3rd): 15 h. + +IRC, freenode, #hurd, 2011-07-23 + + < antrik> tschwinge: yes, the system definitely gets slower with + time. after running for a couple of weeks, it needs at least twice as + long to open a new shell for example + < antrik> I don't know whether this is only related to swap usage, or there + are some serious fragmentation issues + < braunr> antrik: both could be induced by fragmentation diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn index 79c2300f..359d5fee 100644 --- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn +++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn @@ -33,3 +33,18 @@ the testee shows that (primarily) an ever-repeating series of `io_seek` and `io_read` is being processed. Running the testee on GNU/Linux with strace shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't as slow as the Hurd's. + +--- + +IRC, freenode, #hurd, 2011-09-01: + + <youpi> hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768 + <youpi> no wonder it's slow + <youpi> unfortunately that's also what it does on linux, the system call is + just less costly + <youpi> apparently gfortran calls io_seek for, like, every token of the + sourced file + <youpi> (fgetpos actually, but that's the same) + <youpi> and it is indeed about 10 times slower under Xen for some reason + +[[!tag open_issue_xen]] diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn new file mode 100644 index 00000000..111d2b88 --- /dev/null +++ b/open_issues/performance/microkernel_multi-server.mdwn @@ -0,0 +1,47 @@ +[[!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]] + +Performance issues due to the microkernel/multi-server system architecture? + +IRC, freenode, #hurd, 2011-07-26 + + < CTKArcher> I read that, because of its microkernel+servers design, the + hurd was slower than a monolithic kernel, is that confirmed ? + < youpi> the hurd is currently slower than current monolithic kernels, but + it's not due to the microkernel + servers design + < youpi> the microkernel+servers design makes the system call path longer + < youpi> but you're bound by disk and network speed + < youpi> so the extra overhead will not hurt so much + < youpi> except dumb applications keeping doing system calls all the time + of course, but they are usually considered bogus + < braunr> there may be some patterns (like applications using pipes + extensively, e.g. git-svn) which may suffer from the design, but still in + an acceptable range + < CTKArcher> so, you are saying that disk and network are more slowing the + system than the longer system call path and because of that, it wont + really matter ? + < youpi> braunr: they should sitll be fixed because they'll suffer (even if + less) on monolithic kernels + < youpi> CTKArcher: yes + < braunr> yes + < CTKArcher> mmh + < youpi> CTKArcher: you might want to listen to AST's talk at fosdem 10 + iirc, about minix + < youpi> they even go as far as using an IPC for each low-level in/out + < youpi> for security + < braunr> this has been expected for a long time + < braunr> which is what motivated research in microkernels + < CTKArcher> I've already downloaded the video :) + < youpi> and it has been more and more true with faster and faster cpus + < braunr> but in 95, processors weren't that fast compared to other + components as they are now + < youpi> while disk/mem haven't evovled so fast diff --git a/open_issues/proc_server_proc_exception_raise.mdwn b/open_issues/proc_server_proc_exception_raise.mdwn new file mode 100644 index 00000000..1d0e92a3 --- /dev/null +++ b/open_issues/proc_server_proc_exception_raise.mdwn @@ -0,0 +1,37 @@ +[[!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_hurd]] + +IRC, freenode, #hurd, 2011-08-11 + + < youpi> in which error cases a reply port will actually have been consumed + by mach_msg ? + < youpi> it seems at least MACH_SEND_NOTIFY_IN_PROGRESS do? + < braunr> + http://www.gnu.org/software/hurd/gnumach-doc/Message-Send.html#Message-Send + < braunr> "These return codes imply that the message was returned to the + caller with a pseudo-receive operation: " + < braunr> isn't it what you're looking for ? + < youpi> well, it's hard to tell from the name + < youpi> I don't know what "pseudo-receiv operation" means + < braunr> it's described below + < youpi> ew + < braunr> it looks close enough to a normal receive to assume it consumes + the reply port + < youpi> so it's even more complex than what I thought + < youpi> well, no, it returns the right + < youpi> actually the error I'm getting is MACH_RCV_INVALID_NAME + < youpi> which I guess means the sending part succeeded + < youpi> the case at stake is proc/mgt.c: S_proc_exception_raise() + < youpi> when the proc_exception_raise() forward fails + < youpi> currently we always return 0, but if proc_exception_raise() + actually managed to send the message, the reply port was consumed and + MIG_NO_REPLY should be returned instead diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn index 760c7d66..1558bebb 100644 --- a/open_issues/resource_management_problems.mdwn +++ b/open_issues/resource_management_problems.mdwn @@ -61,7 +61,22 @@ This is, of course, non-trivial to implement, and also requires changing the SPLICE_F_GIFT flag](http://www.kernel.org/doc/man-pages/online/pages/man2/vmsplice.2.html#DESCRIPTION).) +IRC, freenode, #hurd, 2011-07-31 + + < braunr> one of the biggest problems on the hurd is that, when a client + makes a call, kernel (and other) resources are allocated on behalf of the + server performaing the requested action + < braunr> performing* + < braunr> this makes implementing scheduling and limits difficult + < CTKArcher> And could changing the kernel change anything to that ? + < braunr> yes but you'd probably need to change its interface as well + < braunr> iirc, the critique describes resource containers + < braunr> but no work has been done on the current hurd (hence the hurdng + attempts) + # Further Examples + * [[IO_accounting]] + * [[configure max command line length]] diff --git a/open_issues/resource_management_problems/io_accounting.mdwn b/open_issues/resource_management_problems/io_accounting.mdwn new file mode 100644 index 00000000..113b965a --- /dev/null +++ b/open_issues/resource_management_problems/io_accounting.mdwn @@ -0,0 +1,49 @@ +[[!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]]."]]"""]] + +IRC, freenode, #hurd, 2011-07-22 + + <braunr> an interesting question i've had in mind for a few weeks now is + I/O accounting + <braunr> what *is* I/O on a microkernel based system ? + <braunr> can any cross address space transfer be classified as I/O ? + +IRC, freenode, #hurd, 2011-07-29 + + < braunr> how does the hurd account I/O ? + < youpi> I don't think it does + < youpi> not an easy task, actually + < youpi> since gnumach has no idea about it + < braunr> yes + < braunr> another centralization issue + < braunr> does network access count as I/O on linux ? + < youpi> no + < braunr> not even nfs ? + < youpi> else you'd get 100% for servers :) + < braunr> right + < youpi> nfs goes through vfs first + < braunr> i'll rephrase my question + < youpi> I'd need to check but I believe it can check nfs + < braunr> does I/O accounting occur at the vfs level or block layer ? + < youpi> I don't know, but I beleive vfs + < youpi> (at least that's how I'd do it) + < braunr> i don't have any more nfs box to test that :/ + < braunr> personally i'd do it at the block layer :) + < youpi> well, both + < youpi> so e2fsck can show up too + < braunr> yes + < youpi> it's just a matter of ref counting + < youpi> apparently nfs doesn't account + < youpi> find . -printf "" doesn't show up in waitio + < braunr> good + < youpi> well, depends on the point of view + < youpi> as a user, you'd like to know whether your processes are stuck on + i/o (be it disk or net) + < braunr> this implies clearly defining what io is diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn b/open_issues/sa_siginfo_sa_sigaction.mdwn index d6199b6a..3b8edff7 100644 --- a/open_issues/sa_siginfo_sa_sigaction.mdwn +++ b/open_issues/sa_siginfo_sa_sigaction.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 @@ -45,3 +45,50 @@ IRC, #hurd, August / September 2010: <youpi> (i.e. replace with 0 in your example) <giselher> ok <youpi> when SA_SIGINFO becomes available, it'll just be used + +IRC, freenode, #hurd, 2011-08-20: + + < youpi> erf, tcpwrappers will need si_pid + < jkoenig> I could implement it not too far away in the future, we just + need a version of msg_sig_post() with a siginfo argument or something. + < youpi> I can also see a lot of packages using SA_SIGINFO for no reason... + < youpi> (probably copy/pasty code) + < youpi> sa.sa_flags = SA_SIGINFO; + < youpi> sa.sa_handler = parse_config; + < youpi> void parse_config(int) + < youpi> yay + < youpi> if(siginf->si_signo == SIGXCPU) + < youpi> fprintf(stderr, "Exceeded CPU usage.\n"); + < youpi> ... + < youpi> jkoenig: actually most package don't actually use the SA_SIGINFO + they request... + < youpi> jkoenig: si_pid should get us almost all actually used coverage + < youpi> I've seen only one example using si_errno + < jkoenig> ok + < youpi> oh, it's actually supported by your patch + < youpi> (errno) + < jkoenig> but I guess since implementing si_pid will require a new RPC, we + might as well plan for the rest + < youpi> jkoenig: indeed + < jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances? + < youpi> ok, well, we'll see + < pinotree> jkoenig: if it can be of help, boost::unit_test queries various + fields of siginfo_t depending on the signal + < pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting + memory on SIGBUS + < jkoenig> pinotree, oh ok good to know + < pinotree> *faulty + < youpi> jkoenig: well, I guess you had checked that the si_addr field is + correct in a few simple testcase :) + < jkoenig> hmm I think so, yes + < jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC + < youpi> ok + < jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV + depending on the upper bit, or something (I can't quite remember) + < jkoenig> but when sigsegv was generated si_addr was right. + < pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost + sources) + < pinotree> maybe you can try the unit tests for boost::unit_tests, if any + :) + < pinotree> (while src/pulsecore/memtrap.c in PA) + * pinotree stops doing MrObvious™ diff --git a/open_issues/sbcl.mdwn b/open_issues/sbcl.mdwn new file mode 100644 index 00000000..4bbf92ef --- /dev/null +++ b/open_issues/sbcl.mdwn @@ -0,0 +1,31 @@ +[[!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_porting]] + +IRC, freenode, #hurd, 2011-08-12 + + < zyg> did the segment registers had any purpose? I see fs is set equal to + others, but on linux fs is 0 (atleast on this x86 box). + < braunr> zyg: it can be used by special applications like wine, yes + < zyg> braunr: thanks.. I'm reading up on linux actually. It seems gs can + be used for TLS, fs in syscall to pass userspace. + < braunr> zyg: why are you interested in that ? + < zyg> a native compiler under linux places assumptions on fs register. So + I'm trying to find out what it should do under gnumach/hurd. + < braunr> what compiler ? + < zyg> braunr: it's sbcl + < braunr> ok + < youpi> zyg: the same, basically + < zyg> ok.. looking at the code, I've remarked where it sets up FS, because + /usr/include/asm/ldt.h:struct user_desc is missing. I must search for the + equiv. + < youpi> zyg: mach/i386/mach_i386.h + < youpi> the descriptor structure diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn index 2deec7e8..c613e21c 100644 --- a/open_issues/sendmsg_scm_creds.mdwn +++ b/open_issues/sendmsg_scm_creds.mdwn @@ -90,6 +90,10 @@ IRC, unknown channel, unknown date. <pinotree> yep <youpi> ok, good :) +/!\ IRC, freenode, #hurd, 2011-08-11 + + < pinotree> (but that patch is lame) + --- See also [[pflocal_socket_credentials_for_local_sockets]] and [[pflocal_reauth]]. diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn index 778933a7..5fec38b1 100644 --- a/open_issues/syslog.mdwn +++ b/open_issues/syslog.mdwn @@ -1,7 +1,45 @@ IRC, unknwon channel, unknown date. - <tschwinge> scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 I see that you intend(ed) to use syslog for logging debug messages. I thought I'd point you to http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no idea if that's still an issue or what went wrong at that time. Perhaps you can have a look? - <scolobb> tschwinge: Thanks for information! Currently I'm logging some debug messages to a simple file, but I'll now check whether the issue you've pointed out is still present. - <scolobb> tschwinge: I am getting absolutely abnormal results: when I call syslog() from a simple C program for the first time, the message goes to the system log. However, any further calls to syslog() do just nothing... I am able to send something to syslog only after reboot (it doesn't help if I restart syslogd). + <tschwinge> scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 + I see that you intend(ed) to use syslog for logging debug messages. I + thought I'd point you to + http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no + idea if that's still an issue or what went wrong at that time. Perhaps + you can have a look? + <scolobb> tschwinge: Thanks for information! Currently I'm logging some + debug messages to a simple file, but I'll now check whether the issue + you've pointed out is still present. + <scolobb> tschwinge: I am getting absolutely abnormal results: when I call + syslog() from a simple C program for the first time, the message goes to + the system log. However, any further calls to syslog() do just + nothing... I am able to send something to syslog only after reboot (it + doesn't help if I restart syslogd). +IRC, freenode, #hurd, 2011-08-08 + + < pinotree> wow, `logger` + a simple C udp server can cause havoc + < pinotree> youpi: ever seen something like + http://paste.debian.net/hidden/72cf4b77/ ? + < pinotree> and then also other servers (like pflocal, pfinet, few more) + start becoming crazy (using 100% cpu) + < youpi> nope + < pinotree> iirc in one of the few tries i got the message "Resource lost." + from the closed ssh connection + < pinotree> i was trying to see why syslog doesn't work, but this basically + surprised me... + < pinotree> oh, i found an apparently working syslog daemon + < pinotree> dsyslog + < gg0> have you tried syslog-ng? IIRC it writes in /var/log/messages by + default. + < pinotree> yeah, it seems to stop receiving messages are few + < pinotree> gg0: are you using syslog-ng? + < gg0> pinotree: I should fire hurd vm up. I seem I kept dirty-patched + busybox syslog, I don't even know if it works, at least it starts + http://bugs.debian.org/636162 + < pinotree> maintainer said "not really" + < gg0> well, if all other syslogs use shm and sems, they won't work too, + right? + < youpi> shm should work with the latest libc + < youpi> what won't is sysv sem + < youpi> (i.e. semget) diff --git a/open_issues/tty_activitiy_vs_disk_io.mdwn b/open_issues/tty_activitiy_vs_disk_io.mdwn new file mode 100644 index 00000000..26382d56 --- /dev/null +++ b/open_issues/tty_activitiy_vs_disk_io.mdwn @@ -0,0 +1,81 @@ +[[!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_hurd]] + +IRC, freenode, #hurd, 2011-07-25 + + < youpi> Mmm, typing something on the mach console triggers a write on the + disk + < youpi> because the /dev/console node gets updated + < youpi> I don't really see why + < youpi> (yes, just typing at the bash prompt, not even running something) + < youpi> typing during the sleep command (i.e. mere tty echo) doesn't + trigger it, however + < youpi> running bash's echo does trigger it + < braunr> during sleep, the glibc stream functions handle I/O, while with + bash, its readline takes care of it, right ? + < youpi> /bin/echo too + < youpi> during sleep it's the tty process which handles I/O + < braunr> the write may be due to a write time update on the inode + < braunr> modification* time + < youpi> probably yes, but how so? + < youpi> ext2fs is only supposed to pass the thing to the console + translator + < braunr> not sure + < youpi> actually, ext2fs even isn't supposed to come into play when it's + about typing at the bash prompt + < youpi> once it's opened, isn't the port for /dev/console supposed to be + directly to the translator there? + < braunr> i think so + < youpi> (s/tty/term/ in what I said) + < braunr> well, it's certain + < youpi> so I don't see how ext2fs can be triggered to write an atime or + mtime + < braunr> what does rpctrace say ? + < youpi> io_read_request and io_write_request + < youpi> braunr: it doesn't happen at the login prompt + < youpi> interestingly, atime is always 3-4 secs earlier than ctime & mtime + < youpi> doesn't happen with dash + < braunr> we should implement relatime and experiment with it + < braunr> it shouldn't be hard + < youpi> well, there's noatime already + < youpi> but my point is that this update shouldn't happen + < youpi> and I believe it's the source of the i_file_acl e2fsck warning + < braunr> i wasn't saying that concerning this problem, it was just a + separate idea (noatime is more problematic than relatime) + < braunr> and i agree, it shouldn't happen :) + < youpi> ok, it's set_node_times which gets called + +IRC, freenode, #hurd, 2011-07-27 + + < antrik> BTW, I'm not sure it's still relevant; but the reason accessing + translators such as the console modifies the underlying node is that most + stat information is generally passed through + < antrik> (in some cases it might be unintentional though, simply using the + default implementation from trivfs carelessly...) + < youpi> I know + < youpi> I've seen that in the code + < antrik> OK + < youpi> it is still relevant: I still find it useless to write it on the + disk + < youpi> though w uses it to show idle time over reboot + < braunr> is it useful to keep the information across reboots ? + < youpi> for some value of "useful" for w + < braunr> i wonder what would break if this was entierly kept in memory + < youpi> nothing, probably + < youpi> note that it doesn't overload ext2fs so much, it just adds a write + every ~5s + < youpi> (at worse, i.e. when keeping showing text, for instance) + < braunr> indeed, the behaviour seems the same on linux + < antrik> ah... that explains why the disk doesn't spin down while IRC is + active... always wondered about that :-) + < youpi> that's not very power-saving, yes + < youpi> well, we might want to put /dev on ram someday diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn index b8061f71..e929f2bf 100644 --- a/open_issues/user-space_device_drivers.mdwn +++ b/open_issues/user-space_device_drivers.mdwn @@ -33,6 +33,16 @@ Also see [[device drivers and IO systems]]. to IRQs. However, at least in GNU Mach, that code (`kern/eventcount.c`) doesn't seem functional at all and isn't integrated properly in the kernel. + * IRC, freenode, #hurd, 2011-07-29 + + < antrik> regarding performance of userspace drivers, there is one + thing that really adds considerable overhead: interrupt + handling. whether this is relevant very much depends on the hardware + in question. when sending many small packets over gigabit ethernet, + it might be noticable; in most other cases it's irrelevant + < youpi> some cards support interrupt coalescin + < youpi> could be supported by DDE too + ## DMA * Security considerations. @@ -52,6 +62,32 @@ Also see [[device drivers and IO systems]]. * [[GNU Mach|microkernel/mach/gnumach]] is said to have a high overhead when doing RPC calls. +## System Boot + +IRC, freenode, #hurd, 2011-07-27 + + < braunr> btw, was there any formulation of the modifications required to + have disk drivers in userspace ? + < braunr> (which would obviously need something like + initrd/initramfs/whatever and may also need the root file system not to + be the first task started) + < braunr> hm actually, we may not need initrd + < braunr> the boot loader could just load more modules + < antrik> braunr: I have described all that in my thesis report... in + German :-( + < braunr> and the boot scripts could be adjusted to pass around the right + ports + < Tekk_> braunr: yeah, we could probably load a module that kciks us into + userspace and starts the disk driver + < braunr> modules are actualy userspace executables + < Tekk_> ah + < Tekk_> so what's the issue? + < Tekk_> oh! I'm thinking the ext2fs server, which is already in userspce + < braunr> change the file systems to tell them which underlying disk driver + to use + < Tekk_> mhm + < braunr> s/disk/storage/ + # Plan diff --git a/open_issues/wine.mdwn b/open_issues/wine.mdwn index 85d35c9c..65e6c584 100644 --- a/open_issues/wine.mdwn +++ b/open_issues/wine.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 @@ -19,3 +19,51 @@ requirements Wine has: only libc / POSIX / etc., or if there are [[Samuel|samuelthibault]] suspects that *there's some need for LDT table allocation. There is kernel support for this,* however. + + +IRC, freenode, #hurd, 2011-08-11 + + < arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM, + and to that end, I've successfully compiled the latest sources from Git + after installing the libc (devel) packages from experimental and + personally patching Wine with http://pastebin.com/rg6dx09G + +[[rg6dx09G.patch]] + + < arethusa> my question is, when trying to launch Wine, I'm seeing "wine + client error:0: sendmsg: (os/kern) invalid address" from the client side, + whereas the wineserver seems to be starting and running correctly, how + could I debug this issue further? using rpctrace doesn't seem to help, as + the trace just hangs when run on the Wine loader instead of yielding + insight + < kilobug> arethusa: isn't there a wine debuguer that can start a gdb when + wine encounters an error or something like that ? + < arethusa> it's too early for that + < kilobug> or least give you a full traceback of the wine code where the + error occur ? + < arethusa> the error is happening during initial connect to the + wineserver, in dlls/ntdll/server.c + < arethusa> but that doesn't help me figure out why sendmsg would error out + in this way + < arethusa> + http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l361 + < azeem_> arethusa: probably some of the msghdr entries are not supported + by the Hurd's glib + < azeem_> c + < pinotree> haha, socket credentials, which we don't support yet + < azeem_> yep + < pinotree> youpi: ↑ another case ;) + < azeem_> arethusa: just implement those and it should work + < kilobug> in pflocal ? or glibc ? + < pinotree> pflocal + < arethusa> azeem_: hmm, okay, thanks + < pinotree> arethusa: their lack is a known issue, and makes things like + dbus and gamin not work + < arethusa> it's + https://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html and + related links I assume? + +[[sendmsg_scm_creds]] + + < youpi> yes + < pinotree> (but that patch is lame) diff --git a/open_issues/wine/rg6dx09G.patch b/open_issues/wine/rg6dx09G.patch new file mode 100644 index 00000000..510ff23f --- /dev/null +++ b/open_issues/wine/rg6dx09G.patch @@ -0,0 +1,116 @@ +diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c
+index 42b3639..7484608 100644
+--- a/dlls/ntdll/directory.c
++++ b/dlls/ntdll/directory.c
+@@ -3145,14 +3145,14 @@ static void WINAPI read_changes_user_apc( void *arg, IO_STATUS_BLOCK *io, ULONG
+ static NTSTATUS read_changes_apc( void *user, PIO_STATUS_BLOCK iosb, NTSTATUS status, void **apc )
+ {
+ struct read_changes_info *info = user;
+- char data[PATH_MAX];
++ char data[4096];
+ NTSTATUS ret;
+ int size;
+
+ SERVER_START_REQ( read_change )
+ {
+ req->handle = wine_server_obj_handle( info->FileHandle );
+- wine_server_set_reply( req, data, PATH_MAX );
++ wine_server_set_reply( req, data, 4096 );
+ ret = wine_server_call( req );
+ size = wine_server_reply_size( reply );
+ }
+diff --git a/dlls/ntdll/signal_i386.c b/dlls/ntdll/signal_i386.c
+index 6c8e8e2..e949227 100644
+--- a/dlls/ntdll/signal_i386.c
++++ b/dlls/ntdll/signal_i386.c
+@@ -180,6 +180,36 @@ __ASM_GLOBAL_FUNC(vm86_enter,
+
+ #endif /* linux */
+
++#ifdef __GNU__
++
++typedef ucontext_t SIGCONTEXT;
++
++#define EAX_sig(context) ((context)->uc_mcontext.gregs[REG_EAX])
++#define EBX_sig(context) ((context)->uc_mcontext.gregs[REG_EBX])
++#define ECX_sig(context) ((context)->uc_mcontext.gregs[REG_ECX])
++#define EDX_sig(context) ((context)->uc_mcontext.gregs[REG_EDX])
++#define ESI_sig(context) ((context)->uc_mcontext.gregs[REG_ESI])
++#define EDI_sig(context) ((context)->uc_mcontext.gregs[REG_EDI])
++#define EBP_sig(context) ((context)->uc_mcontext.gregs[REG_EBP])
++#define ESP_sig(context) ((context)->uc_mcontext.gregs[REG_ESP])
++
++#define CS_sig(context) ((context)->uc_mcontext.gregs[REG_CS])
++#define DS_sig(context) ((context)->uc_mcontext.gregs[REG_DS])
++#define ES_sig(context) ((context)->uc_mcontext.gregs[REG_ES])
++#define SS_sig(context) ((context)->uc_mcontext.gregs[REG_SS])
++#define FS_sig(context) ((context)->uc_mcontext.gregs[REG_FS])
++#define GS_sig(context) ((context)->uc_mcontext.gregs[REG_GS])
++
++#define EFL_sig(context) ((context)->uc_mcontext.gregs[REG_EFL])
++#define EIP_sig(context) ((context)->uc_mcontext.gregs[REG_EIP])
++#define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO])
++#define ERROR_sig(context) ((context)->uc_mcontext.gregs[REG_ERR])
++
++#define FPU_sig(context) ((FLOATING_SAVE_AREA *)&(context)->uc_mcontext.fpregs.fp_reg_set.fpchip_state)
++#define FPUX_sig(context) NULL
++
++#endif /* __GNU__ */
++
+ #ifdef BSDI
+
+ #include <machine/frame.h>
+diff --git a/dlls/shell32/shfldr_unixfs.c b/dlls/shell32/shfldr_unixfs.c
+index 9649df8..cdd1798 100644
+--- a/dlls/shell32/shfldr_unixfs.c
++++ b/dlls/shell32/shfldr_unixfs.c
+@@ -369,7 +369,7 @@ static inline BOOL UNIXFS_is_pidl_of_type(LPCITEMIDLIST pIDL, SHCONTF fFilter) {
+ static BOOL UNIXFS_get_unix_path(LPCWSTR pszDosPath, char *pszCanonicalPath)
+ {
+ char *pPathTail, *pElement, *pCanonicalTail, szPath[FILENAME_MAX], *pszUnixPath, has_failed = 0, mb_path[FILENAME_MAX];
+- WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[PATH_MAX], *dospath_end;
++ WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[MAX_PATH], *dospath_end;
+ int cDriveSymlinkLen;
+ void *redir;
+
+diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c
+index ad8e08b..a8d6329 100644
+--- a/dlls/winex11.drv/xrender.c
++++ b/dlls/winex11.drv/xrender.c
+@@ -2440,8 +2440,8 @@ void X11DRV_XRender_UpdateDrawable(X11DRV_PDEVICE *physDev)
+ return;
+ }
+
+-BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, X11DRV_PDEVICE *devSrc,
+- struct bitblt_coords *dst, struct bitblt_coords *src, BLENDFUNCTION blendfn )
++BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, struct bitblt_coords *dst,
++ X11DRV_PDEVICE *devSrc, struct bitblt_coords *src, BLENDFUNCTION blendfn )
+ {
+ FIXME("not supported - XRENDER headers were missing at compile time\n");
+ return FALSE;
+diff --git a/libs/wine/ldt.c b/libs/wine/ldt.c
+index 3098061..b3fee13 100644
+--- a/libs/wine/ldt.c
++++ b/libs/wine/ldt.c
+@@ -96,6 +96,11 @@ static inline int set_thread_area( struct modify_ldt_s *ptr )
+ #include <i386/user_ldt.h>
+ #endif
+
++#ifdef __GNU__
++#include <mach/i386/mach_i386.h>
++#include <mach/mach_traps.h>
++#endif
++
+ /* local copy of the LDT */
+ #ifdef __APPLE__
+ struct __wine_ldt_copy wine_ldt_copy = { { 0, 0, 0 } };
+@@ -203,6 +208,9 @@ static int internal_set_entry( unsigned short sel, const LDT_ENTRY *entry )
+ #elif defined(__APPLE__)
+ if ((ret = i386_set_ldt(index, (union ldt_entry *)entry, 1)) < 0)
+ perror("i386_set_ldt");
++#elif defined(__GNU__)
++ if ((ret = i386_set_ldt(mach_thread_self(), sel, (descriptor_list_t)entry, 1)) != KERN_SUCCESS)
++ perror("i386_set_ldt");
+ #else
+ fprintf( stderr, "No LDT support on this platform\n" );
+ exit(1);
\ No newline at end of file |