summaryrefslogtreecommitdiff
path: root/open_issues
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues')
-rw-r--r--open_issues/active_vs_passive_symlink_translator.mdwn44
-rw-r--r--open_issues/clock_gettime.mdwn28
-rw-r--r--open_issues/code_analysis.mdwn7
-rw-r--r--open_issues/glibc_init_first.mdwn78
-rw-r--r--open_issues/gnumach_memory_management.mdwn397
-rw-r--r--open_issues/hurd_101.mdwn38
-rw-r--r--open_issues/libpthread_dlopen.mdwn30
-rw-r--r--open_issues/mach_tasks_memory_usage.mdwn49
-rw-r--r--open_issues/mmap_crash_etc.mdwn95
-rw-r--r--open_issues/multiprocessing.mdwn37
-rw-r--r--open_issues/packaging_libpthread.mdwn5
-rw-r--r--open_issues/performance.mdwn4
-rw-r--r--open_issues/performance/degradation.mdwn28
-rw-r--r--open_issues/performance/io_system/binutils_ld_64ksec.mdwn15
-rw-r--r--open_issues/performance/microkernel_multi-server.mdwn47
-rw-r--r--open_issues/proc_server_proc_exception_raise.mdwn37
-rw-r--r--open_issues/resource_management_problems.mdwn15
-rw-r--r--open_issues/resource_management_problems/io_accounting.mdwn49
-rw-r--r--open_issues/sa_siginfo_sa_sigaction.mdwn49
-rw-r--r--open_issues/sbcl.mdwn31
-rw-r--r--open_issues/sendmsg_scm_creds.mdwn4
-rw-r--r--open_issues/syslog.mdwn44
-rw-r--r--open_issues/tty_activitiy_vs_disk_io.mdwn81
-rw-r--r--open_issues/user-space_device_drivers.mdwn36
-rw-r--r--open_issues/wine.mdwn50
-rw-r--r--open_issues/wine/rg6dx09G.patch116
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