summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2013-04-07 18:28:11 +0200
committerThomas Schwinge <thomas@codesourcery.com>2013-04-07 18:28:11 +0200
commit325d3600adae1a2da62f9a24ac34ad2b47a22f97 (patch)
treef0637c13c8aec0d0793f7d2498f5e2237e693c4b
parentacab07dfc9df44d6d54e03c701a90b5d6f537fcd (diff)
parent6c7d45e4631784d0e077e806521a736da6b0266e (diff)
Merge remote-tracking branch 'fp/master'
Conflicts: hurd.mdwn hurd/debugging/rpctrace.mdwn open_issues/clock_gettime.mdwn open_issues/time.mdwn
-rw-r--r--community/gsoc/project_ideas/smp.mdwn11
-rw-r--r--faq/support/smp.mdwn5
-rw-r--r--hurd.mdwn1
-rw-r--r--hurd/debugging/rpctrace.mdwn8
-rw-r--r--hurd/libihash.mdwn17
-rw-r--r--hurd/libps.mdwn27
-rw-r--r--hurd/translator/ext2fs.mdwn31
-rw-r--r--hurd/translator/pfinet/implementation.mdwn51
-rw-r--r--hurd/translator/pfinet/ipv6.mdwn14
-rw-r--r--hurd/translator/tarfs.mdwn15
-rw-r--r--microkernel/mach/deficiencies.mdwn136
-rw-r--r--open_issues/anatomy_of_a_hurd_system.mdwn29
-rw-r--r--open_issues/clock_gettime.mdwn9
-rw-r--r--open_issues/glibc/debian/experimental.mdwn115
-rw-r--r--open_issues/libpthread.mdwn13
-rw-r--r--open_issues/linux_vmsig.mdwn17
-rw-r--r--open_issues/managed_runtime_initiative.mdwn72
-rw-r--r--open_issues/multithreading.mdwn27
-rw-r--r--open_issues/nice_vs_mach_thread_priorities.mdwn40
-rw-r--r--open_issues/performance/io_system/read-ahead.mdwn42
-rw-r--r--open_issues/pfinet_timers.mdwn102
-rw-r--r--open_issues/translate_fd_or_port_to_file_name.mdwn70
-rw-r--r--open_issues/virtualization/fakeroot.mdwn7
-rw-r--r--open_issues/virtualization/remap_root_translator.mdwn5
24 files changed, 841 insertions, 23 deletions
diff --git a/community/gsoc/project_ideas/smp.mdwn b/community/gsoc/project_ideas/smp.mdwn
index d9788e56..c6da2c41 100644
--- a/community/gsoc/project_ideas/smp.mdwn
+++ b/community/gsoc/project_ideas/smp.mdwn
@@ -10,6 +10,8 @@ License|/fdl]]."]]"""]]
[[!meta title="SMP"]]
+See also the [[FAQ entry|faq/smp]].
+
# IRC, freenode, #hurd, 2012-09-30
@@ -19,3 +21,12 @@ License|/fdl]]."]]"""]]
## IRC, freenode, #hurd, 2013-01-02
<braunr> i'd like to mentor someone for adding smp to gnumach
+
+
+## IRC, freenode, #hurd, 2013-03-14
+
+ <braunr> but i'm afraid we'll have to fight obscur smp-safety issues
+ <braunr> for one, drivers are much probably not smp safe and would require
+ a big kernel lock
+ <braunr> userspace (such as signal delivery in libc) might be affected too
+ <braunr> smp isn't that easy
diff --git a/faq/support/smp.mdwn b/faq/support/smp.mdwn
index e95edcd2..04396401 100644
--- a/faq/support/smp.mdwn
+++ b/faq/support/smp.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2011, 2013 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
@@ -26,3 +27,5 @@ That is why for now GNU/Hurd will only use one logical processor (i.e. one core
Once this issue is solved, there are follow-up issues about
[[open_issues/multiprocessing]] and [[open_issues/multithreading]].
+
+[[GSoC project idea|gsoc/project_ideas/smp]].
diff --git a/hurd.mdwn b/hurd.mdwn
index f005bd6b..ed88f09f 100644
--- a/hurd.mdwn
+++ b/hurd.mdwn
@@ -94,6 +94,7 @@ in the *unstable* branch of the Debian archive.
* [[libihash]]
* [[libpthread]]
* [[libfshelp]]
+ * [[libps]]
* In-development Libraries
* [[libfuse]]
* Discontinued Libraries
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index e7fa81ec..a5c1a6e9 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -175,8 +175,12 @@ See `rpctrace --help` about how to use it.
/home/rbraun/hd0s7/hurd/hurd-20120710/./utils/rpctrace.c:1287:
trace_and_forward: Assertion `reply_type == 18' failed.
-This assertion is actually caused by using the io_select interface, which creates
-a send right instead of a send-once right for the reply port (IIRC).
+ This assertion is actually caused by using the io_select interface, which creates
+ a send right instead of a send-once right for the reply port (IIRC).
+
+ * IRC, OFTC, #debian-hurd, 2013-03-14
+
+ <youpi> uhu, there's a TODO just above that assertion :)
# See Also
diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn
index d6b8e8b6..be20fa58 100644
--- a/hurd/libihash.mdwn
+++ b/hurd/libihash.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2010, 2011, 2012 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2009, 2010, 2011, 2012, 2013 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,19 +19,26 @@ License|/fdl]]."]]"""]]
* hurd-l4 libhurd-ihash
+
+# Open Issues
+
* [[viengoos libhurd-ihash|microkernel/viengoos/projects/new_hash_function]]
- IRC, unknown channel, unknown date
+ IRC, freenode, #hurd, 2008/2009
<neal> so, we need a new ihash implementation
<neal> marcusb: When 80% full, the collision rate is very high.
<neal> marcusb: I tested using 512mb / 4096 entries
- <neal> marcusb: Changing the load factor to 30% resulted in my program running more than an order of magnitude faster.
+ <neal> marcusb: Changing the load factor to 30% resulted in my program
+ running more than an order of magnitude faster.
<marcusb> yeah, it shouldn't get so full
<marcusb> don't we do an exponential back-off in the array size?
<marcusb> of course it's clear we can do much better
<marcusb> the ihash algo is very simple
- <marcusb> I'm not even sure it makes much sense to have a generic library
+ <marcusb> I'm not even sure it makes much sense to have a generic
+ library
+
+ * [[community/gsoc/project_ideas/object_lookups]]
# Alternatives?
diff --git a/hurd/libps.mdwn b/hurd/libps.mdwn
new file mode 100644
index 00000000..05ab3ad1
--- /dev/null
+++ b/hurd/libps.mdwn
@@ -0,0 +1,27 @@
+[[!meta copyright="Copyright © 2013 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]]."]]"""]]
+
+`libps` provides an API for accessing process information. An alternative is a
+[[Linux-compatible `/proc` filesystem|translator/procfs]].
+
+
+# IRC, OFTC, #debian-hurd, 2013-03-09
+
+[[!tag open_issue_documentation]]
+
+ <Steap> what's the difference between PSTAT_STATE_P_STOP and
+ PSTAT_STATE_T_HALT in libps/ps.h ?
+ <youpi> Steap: from reading the gnumach source, it seems halted threads are
+ thread which have finished they work but not finished terminating yet
+ <youpi> while STOP is the standard preempted state
+ <youpi> i.e. not sleeping, but have handed cpu to another thread
+ <Steap> youpi: thanks. Is this "halted" state similar to anything in Linux
+ ?
+ <youpi> TASK_DEAD, probably
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index bc43644f..a89b40b1 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -89,6 +89,37 @@ small backend stores, like floppy devices.
<youpi> which can be quite probable
+##### IRC, freenode, #hurd, 2013-03-19
+
+ <braunr> youpi: i'm back on polishing the large store patch
+ <braunr> did you remember seeing something else than the bzero/memset
+ out-of-scope changes ?
+ <braunr> (i mean, readily noticeable)
+ <youpi> I don't remember
+ <braunr> ok
+ <braunr> the original code already assumes mmap succeeds
+ <braunr> is it ok to consider the patch can do the same ?
+ <youpi> I'd say so
+ <braunr> ok
+ <braunr> youpi: actually, it looks like a good part of the patch isn't
+ related to large stores
+ <braunr> for example, in ext2fs/inode.c, there are calls to
+ dino_ref/dino_deref
+ <youpi> hum
+ <braunr> i'm not sure at all these have anything to do with handling large
+ stores
+ <youpi> but dino_ref is introduced by this patch, isn't it?
+ <braunr> it replaces dino
+ <youpi> yes, it replaces it because the dino() approach can't work beyond
+ 2GiB
+ <braunr> i see
+ <braunr> youpi: i'd like to replace the recursive call to
+ disk_cache_block_ref with a goto, is that fine with you ?
+ <youpi> looks ok to me
+ <youpi> better than relying on tail recursion
+ <braunr> that's the idea :)
+
+
#### [[libpager]] API change
##### IRC, freenode, #hurd, 2013-03-04
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 50b5dfc2..3232e0cc 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -1,13 +1,58 @@
-[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2000, 2008, 2013 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
The `pfinet` server is a hacked Linux internet implementation with a glue layer
translating between the Hurd [[RPC]]s and the middle layer of the Linux
implementation.
+
+
+# Bugs
+
+## Those Listed on [[Open_Issues]]
+
+## [[IPv6]]
+
+## IRC, freenode, #hurd, 2013-04-03
+
+ <braunr> youpi: there are indeed historical bugs with small packets and
+ tcp_nodelay in linux 2.0/2.2 tcp/ip
+ <youpi> oh
+ <braunr> http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html
+
+
+# Reimplementation, [[!GNU_Savannah_task 5469]]
+
+## IRC, freenode, #hurd, 2013-04-03
+
+[[!tag open_issue_hurd]]
+
+ <youpi> I was thinking about just using liblwip this afternoon, btw
+ <braunr> what is it ?
+ <braunr> hm, why not
+ <braunr> i would still prefer using code from netbsd
+ <braunr> especially now with the rump kernel project making it even easier
+ <youpi> well, whatever is easy to maintain up to date actually
+ <braunr> netbsd's focus on general portability normally makes it easy to
+ maintain
+ <braunr> the author of the rump project was able to make netbsd code run in
+ browsers :)
+ <braunr> and he actually showed clients using the networking stack on
+ windows, remotely (not in the same process)
+ <braunr> so that's very close to what we want
+ <youpi> indeed
+ <youpi> though liblwip is exactly the same portability focus :)
+ <braunr> apparently, for embedded systems
+ <youpi> but bsd's code is probably better
+ <youpi> yes
+ <braunr> i think so, more general purpose, larger user base
+ <youpi> I used it for the stubdomains in Xen
+ <youpi> (it = lwip)
+ <braunr> ok
diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn
index 79e8f05b..81826e00 100644
--- a/hurd/translator/pfinet/ipv6.mdwn
+++ b/hurd/translator/pfinet/ipv6.mdwn
@@ -147,3 +147,17 @@ Indeed, IPv6 now works properly, and the very machine hosting this wiki
<youpi> I don't remember its url
<braunr> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
<braunr> might be even older
+
+
+## IRC, freenode, #hurd, 2013-04-01
+
+ <congzhan`> hi, the ipv6 route works or not?
+ <congzhan`> I can use ipv6 to connect vms, but the vm can't access other
+ host except the router
+ <congzhan`> the ipv6 route -G seems not work for me, anyone make it work?
+ <youpi> I'm using SLAAC
+ <congzhan`> youpi: you mean static config not work?
+ <youpi> I mean automatic config does work
+ <youpi> I don't use static config myself
+ <congzhang> youpi: My ipv6 works now, just because not fully enable ipv6
+ forwarding and firewall, thank you:)
diff --git a/hurd/translator/tarfs.mdwn b/hurd/translator/tarfs.mdwn
index 4cc5f57a..3eb7b1ed 100644
--- a/hurd/translator/tarfs.mdwn
+++ b/hurd/translator/tarfs.mdwn
@@ -20,6 +20,21 @@ Works fine on most cases, occasional corruptions when writing using bzip2/gzip
stores.
+## IRC, freenode, #hurd, 2013-03-16
+
+[[!tag open_issue_hurd]]
+
+ <pinotree> hm is tarfs working? its simple test suite fails here
+ (translator dies with gz and bz2 compression)
+ <braunr> no idea
+ <braunr> have you tried without compression ?
+ <pinotree> that succeeds
+ <braunr> it might rely on storeio for compression
+ <pinotree> no, it does gz/bz2 on its own
+ <pinotree> but it uses libstore for i/o of the file
+ <braunr> ok
+
+
# Source
[[source_repositories/incubator]], tarfs/master
diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn
index b3e1758c..dcabb56e 100644
--- a/microkernel/mach/deficiencies.mdwn
+++ b/microkernel/mach/deficiencies.mdwn
@@ -615,3 +615,139 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]].
way it is in mach and netbsd
<braunr> but the arch-specific interfaces aren't well defined yet because
there is only one (and incomplete) arch
+
+
+### IRC, freenode, #hurd, 2013-03-08
+
+ <antrik> BTW, what is your current direction? did you follow through with
+ abandonning Mach resemblance?...
+ <braunr> no
+ <braunr> it's very similar to mach in many ways
+ <braunr> unless mach is defined by its ipc in which case it's not mach at
+ all
+ <braunr> the ipc interface will be similar to the qnx one
+ <antrik> well, Mach is pretty much defined by it's IPC and VM interface...
+ <braunr> the vm interface remains
+ <antrik> its
+ <braunr> although vm maps will be first class objects
+ <braunr> so that it will be possible to move parts of the vm server outside
+ the kernel some day if it feels like a good thing to do
+ <braunr> i.e. vm maps won't be inferred from tasks
+ <braunr> not implicitely
+ <braunr> the kernel will be restricted to scheduling, memory management,
+ and ipc, much as mach is (notwithstanding drivers)
+ <antrik> hm... going with QNX IPC still seems risky to me... it's designed
+ for simple embedded environments, not for general-purpose operating
+ systems in my understanding
+ <braunr> no, the qnx ipc interface is very generic
+ <braunr> they can already call remote services
+ <braunr> the system can scale well on multiprocessor machines
+ <braunr> that's not risky at all, on the contrary
+ <antrik> yeah, I'm sure it's generic... but I don't think anybody tried to
+ build a Hurd-like system on top of it; so it's not at all clear whether
+ it will work out at all...
+ <auronandace> clueless question: does x15 have any inspiration from
+ helenos?
+ <braunr> absolutely none
+ <braunr> i'd say x15 is almost an opposite to helenos
+ <braunr> it's meant as a foundation for unix systems, like mach
+ <braunr> some unix interfaces considered insane by helenos people (such as
+ fork and signals) will be implemented (although not completely in the
+ kernel)
+ <braunr> ipc will be mostly synchronous
+ <braunr> they're very different
+ <braunr> well, helenos is very different
+ <auronandace> cool
+ <braunr> x15 and actually propel (the current name i have for the final
+ system), are meant to create a hurd clone
+ <auronandace> another clueless question: any similarities of x15 to minix?
+ <braunr> and since we're few, implementing posix efficiently is a priority
+ goal for me
+ <braunr> again, absolutely none
+ <braunr> for the same reasons
+ <braunr> minix targets resilience in embedded environments
+ <braunr> propel is a hurd clone
+ <braunr> propel aims at being a very scalable and performant hurd clone
+ <braunr> that's all
+ <auronandace> neato
+ <braunr> unfortunately, i couldn't find a name retaining all the cool
+ properties of the hurd
+ <braunr> feel free to suggest ideas :)
+ <auronandace> propel? as in to launch forward?
+ <braunr> push forward, yes
+ <auronandace> that's very likely a better name than anything i could
+ conjure up
+ <braunr> x15 is named after mach (the first aircraft to break mach 4,
+ reaching a bit less than mach 7)
+ <braunr> servers will be engines, and together to push the system forward
+ ..... :)
+ <auronandace> nice
+ <auronandace> thrust might be a bit too generic i guess
+ <braunr> oh i'm looking for something like "hurd"
+ <braunr> doubly recursive acronym, related to gnu
+ <braunr> and short, so it can be used as a c namespace
+ <braunr> antrik: i've thought about it a lot, and i'm convinced this kind
+ of interface is fine for a hurd like system
+ <braunr> the various discussions i found about the hurd requirements
+ (remember roland talking about notifications) all went in this direction
+ <braunr> note however the interface isn't completely synchronous
+ <braunr> and that's very important
+ <antrik> well, I'm certainly curious. but if you are serious about this,
+ you'd better start building a prototype as soon as possible, rather than
+ perfecting SMP ;-)
+ <braunr> i'm not perfecting smp
+ <braunr> but i consider it very important to have migrations and preemption
+ actually working before starting the prototype
+ <braunr> so that tricky mistakes about concurrency can be catched early
+ <antrik> my current hunch is that you are trying to do too much at the same
+ time... improving both the implementation details and redoing the system
+ design
+ <braunr> so, for example, there is (or will be soon, actually) thread
+ migratio, but the scheduler doesn't take processor topology into account
+ <braunr> that's why i'm starting from scratch
+ <braunr> i don't delve too deep into the details
+ <braunr> just the ones i consider very important
+ <antrik> what do you mean by thread migration here? didn't you say you
+ don't even have IPC?...
+ <braunr> i mean migration between cpus
+ <antrik> OK
+ <braunr> the other is too confusing
+ <braunr> and far too unused and unknown to be used
+ <braunr> and i won't actually implement it the way it was done in mach
+ <braunr> again, it will be similar to qnx
+ <antrik> oh? now that's news for me :-)
+ <antrik> you seemed pretty hooked on thread migration when we talked about
+ these things last time...
+ <braunr> i still am
+ <braunr> i'm just saying it won't be implemented the same way
+ <braunr> instead of upcalls from the kernel into userspace, i'll "simply"
+ make server threads inherit from the caller's scheduling context
+ <braunr> the ideas i had about stack management are impossible to apply in
+ practice
+ <braunr> which make the benefit i imagined unrealistic
+ <braunr> and the whole idea was very confusing when compared and integrated
+ into a unix like view
+ <braunr> so stack usage will be increased
+ <braunr> that's ok
+ <antrik> but thread migration is more or less equivalent with first-class
+ RPCs AIUI. does that work with the QNX IPC model?...
+ <braunr> the very important property that threads don't block and wake a
+ server when sending, and the server again blocks and wake the client on
+ reply, is preserved
+ <antrik> (in fact I find the term "first-class RPC" much clearer...)
+ <braunr> i dont
+ <braunr> there are two benefits in practice: since the scheduling context
+ is inherited, the client is charged for the cpu time consumed
+ <braunr> and since there are no wakeups and blockings, but a direct hand
+ off in the scheduler, the cost of crossing task space is closer to the
+ system call
+ <antrik> which can be problematic too... but still it's the solution chosen
+ by EROS for example AIUI
+ <antrik> (inheriting scheduling contexts I mean)
+ <braunr> by practically all modern microkernel based systems actually, as
+ noted by shapiro
+ <antrik> braunr: well, both benefits can be achieved by other means as
+ well... scheduler activations like in Viengoos should handle the hand-off
+ part AIUI, and scheduling contexts can be inherited explicitly too, like
+ in EROS (and in a way in Viengoos)
+ <braunr> i don't understand viengoos well enough to do it that way
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index ebb48e24..677e4625 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -351,3 +351,32 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
<braunr>
http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science#Operating_systems
should be a pretty good list :)
+
+
+# IRC, freenode, #hurd, 2013-03-12
+
+ <mjjc> i have a question regarding ipc in hurd. if a task is created, does
+ it contain any default port rights in its space? i am trying to deduce
+ how one calls dir_lookup() on the root translator in glibc's open().
+ <kilobug> mjjc: yes, there are some default port rights, but I don't
+ remember the details :/
+ <mjjc> kilobug: do you know where i should search for details?
+ <kilobug> mjjc: hum either in the Hurd's hacking guide
+ https://www.gnu.org/software/hurd/hacking-guide/ or directly in the
+ source code of exec server/libc I would say, or just ask again the
+ question here later on to see if someone else has more information
+ <mjjc> ok, thanks
+ <pinotree> there's also rpctrace to, as the name says, trace all the rpc's
+ executed
+ <braunr> some ports are introduced in new tasks, yes
+ <braunr> see
+ http://www.gnu.org/software/hurd/hacking-guide/hhg.html#The-main-function
+ <braunr> and
+ <braunr>
+ http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports
+ <mjjc> yes, the second link was just what i was looking for, thanks
+ <braunr> the second is very general
+ <braunr> also, the first applies to translators only
+ <braunr> if you're looking for how to do it for a non-translator
+ application, the answer is probably somewhere in glibc
+ <braunr> _hurd_startup i'd guess
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
index 3caa6c28..5ba6b418 100644
--- a/open_issues/clock_gettime.mdwn
+++ b/open_issues/clock_gettime.mdwn
@@ -188,4 +188,13 @@ In context of [[select]].
<youpi> and we'll make that a 64bit struct when we have a64bit userland
+# IRC, freenode, #hurd, 2013-04-06
+
+ <tschwinge> pinotree: You had once been working on adding nsec-procision
+ timestamps to GNU Mach's maptime interface (or what the name is). Is
+ that blocked on something or just waiting to be continued?
+ <pinotree> blocked on me needing to learn more the proper way to do
+ "atomic" update of the struct with time :)
+
+
# Candidate for [[vDSO]] code?
diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn
new file mode 100644
index 00000000..8d117e99
--- /dev/null
+++ b/open_issues/glibc/debian/experimental.mdwn
@@ -0,0 +1,115 @@
+[[!meta copyright="Copyright © 2013 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]]
+
+Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental.
+
+
+# IRC, OFTC, #debian-hurd, 2013-03-14
+
+ <markus_w1nner> I have a strange tcp via localhost question:
+ <markus_wanner> The other side closes the connection, but I haven't read
+ all data, yet. I should still be able to read the pending data, no?
+ <markus_wanner> At least it seems to work that way on Linux, but not on
+ Hurd.
+ <markus_wanner> Got a simple repro with nc, if you're interested...
+ <youpi> markus_wanner: yes, we're interested
+ <markus_wanner> youpi: okay, here we go:
+ <markus_wanner> session 1: nc -l -p 7777 localhost
+ <markus_wanner> session 2: nc 127.0.0.1 7777
+ <markus_wanner> session 2: a <RET> b <RET> c <RET>
+ <markus_wanner> session 1: [ pause with Ctrl-Z ]
+ <markus_wanner> session 2: [ send more data ] d <RET> e <RET> f <RET>
+ <markus_wanner> session 2: [ quit with Ctrl-C ]
+ <markus_wanner> session 1: [ resume with 'fg' ]
+ <markus_wanner> The server on session 1 doesn't get the data sent after it
+ paused and before the client closed the connection.
+ <markus_wanner> I'm not sure if that's a valid TCP thing. However, on
+ Linux, the server still gets the data. On hurd it doesn't.
+ <markus_wanner> I'm working on a C-code test case, ATM.
+ <youpi> markus_wanner: on which box are you seeing this behavior?
+ <youpi> exodar does not have it
+ <youpi> i.e. I do get the d e f
+ <markus_wanner> a private VM (I'm not a DD)
+ <markus_wanner> ..updated to latest experimental stuff.
+ <markus_wanner> GNU lematur 0.3 GNU-Mach 1.3.99-486/Hurd-0.3 i686-AT386 GNU
+ <youpi> ok, I can't reproduce it on my vm either
+ <youpi> maybe the C program will help
+ <markus_wanner> Hm.. cannot corrently reproduce that in C. (Netcat still
+ shows the issue, though).
+ <markus_wanner> I'll try to strace netcat...
+ <markus_wanner> ..Meh. strace not available on Hurd?
+ <pinotree> no, but there is rpctrace to show the various rpc
+ <markus_wanner> Cool, looks helpful.
+ <markus_wanner> Thx
+ <markus_wanner> Uh.. that introduces another error:
+ <markus_wanner> rpctrace: ../../utils/rpctrace.c:1287: trace_and_forward:
+ Assertion `reply_type == 18' failed.
+
+[[hurd/debugging/rpctrace]].
+
+ <youpi> I'm checking on a box without ipv6 configuration
+ <youpi> maybe that's the difference between you and me
+ <youpi> I guess your /etc/alternatives/nc is /bin/nc.traditional ?
+ <markus_wanner> Yup, nc.traditional.
+ <markus_wanner> Looks like that box only has IPv4 configured.
+ <markus_wanner> Something very strange is going on here. No matter how hard
+ I try, I cannot reproduce this with netcat, anymore.
+ <pinotree> not even after a reboot?
+ <markus_wanner> Woo.. here, it happened, again! This is driving me crazy!
+ <markus_wanner> Now, nc seemingly connects, but is unable to send data
+ between the two. Netcat would somehow complain, if it failed to connect,
+ no?
+ <markus_wanner> No it worked.
+ <markus_wanner> So this seems to be an intermittent issue. So far, I could
+ only ever repro it as a normal user, not as root. May be coincidental,
+ though.
+ <markus_wanner> Now, 'a' and 'b' made it through, but not the 'c' sent
+ manually just after that. Something with that TCP/IP stack is definitely
+ fishy.
+ <markus_wanner> Anything I can try to investigate? Or shall I simply
+ restart and see if the problem persists?
+ <youpi> maybe restart, yes
+ <youpi> did you restart since the upgrade ?
+ <markus_wanner> Yes, I restarted after that.
+ <markus_wanner> Hm.. okay, restarted. Some problem persists.
+ <markus_wanner> I currently have two netcat processes connected, the
+ listening one got some first two messages and seems stuck now.
+ <markus_wanner> With the client, I tried to send more data, but the server
+ doesn't get it, anymore.
+ <markus_wanner> Any idea on what I can do to analyze the situation?
+ <youpi> for the netcat issue, I haven't experienced this
+ <youpi> are you running in kvm or virtualbox or something else?
+ <markus_wanner> I'm currently puzzled about what "experimental" actually
+ ships.
+ <markus_wanner> On kvm.
+ <markus_wanner> My libc0.3 used to be 2.13-39+hurd.3.
+ <markus_wanner> But packages.d.o already shows 2.17.0experimental2.
+ <youpi> experimental ships experimental versions, which you aren't supposed
+ to use
+ <youpi> unless you know what you are doing
+ <youpi> iirc 2.17 is known to be quite broken for now
+ <markus_wanner> Okay. So I guess I'll try to "downgrade" to unstable, then.
+ <markus_wanner> Phew, okay, successfully downgraded to unstable.
+ <markus_wanner> Hopefully monotone's test suite runs through fine, now.
+ <markus_wanner> Yup, WORKING! Looks like some experimental packages caused
+ the problem. The netcat test as well as that one failing monotone test
+ work fine, now.
+
+
+## IRC, OFTC, #debian-hurd, 2013-03-19
+
+ <tschwinge> pinotree, youpi: Is there anything from that markus_wanner
+ discussion about pfinet/netcat/signals that needs to be filed? I guess
+ we don't know what exactly he changed so that everything workedd fine
+ eventually? (Some experimental package(s), but which?)
+ <youpi> that was libc0.3 packages
+ <youpi> which are indeed known to break the network
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index d0ec4119..28532320 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -1281,6 +1281,19 @@ Most of the issues raised on this page has been resolved, a few remain.
<braunr> weird sentence, agreed :p
+### IRC, freenode, #hurd, 2013-03-11
+
+ <braunr> youpi: oh btw, i noticed a problem with the priority adjustement
+ code
+ <braunr> a thread created by a privileged server (e.g. an ext2fs
+ translator) can then spawn a server from a node owned by an unprivileged
+ user
+ <braunr> which inherits the priority
+ <braunr> easy to fix but worth saying to keep in mind
+ <youpi> uh
+ <youpi> indeed
+
+
## IRC, freenode, #hurd, 2012-12-05
<braunr> tschwinge: i'm currently working on a few easy bugs and i have
diff --git a/open_issues/linux_vmsig.mdwn b/open_issues/linux_vmsig.mdwn
index a4311d3e..182fb6f9 100644
--- a/open_issues/linux_vmsig.mdwn
+++ b/open_issues/linux_vmsig.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2013 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
@@ -27,3 +27,18 @@ From a quick glance, this sounds to [[me|tschwinge]] quite a bit like
mechanisms also found in (originating in?) Mach's
[[microkernel/mach/external_pager_mechanism]]. May be worth having a look at
it.
+
+
+# IRC, freenode, #hurd, 2013-03-06
+
+ <braunr> tschwinge: from a quick look, this isn't similar to the external
+ pager mechanism
+ <braunr> it's an additional tool to help userspace application manage
+ internal caches
+ <braunr> it's similar to what is done to reclaim memory from the slab
+ allocator for example
+ <braunr> and it would indeed be a very good thing to have so that e.g. the
+ hurd can build a distributed but completely dynamic dentry-like cache
+ <braunr> i'm actually glad to see someone else thought of using real time
+ signals for this
+ <braunr> i didn't do any research on that subject yet
diff --git a/open_issues/managed_runtime_initiative.mdwn b/open_issues/managed_runtime_initiative.mdwn
new file mode 100644
index 00000000..7a880beb
--- /dev/null
+++ b/open_issues/managed_runtime_initiative.mdwn
@@ -0,0 +1,72 @@
+[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+
+# IRC, freenode, #hurd, 2013-04-02
+
+ <psockali> hi again, maybe someone has some metrics
+ <psockali> is mprotect / munprotect faster in hurd then in linux ?
+ <pinotree> ?
+ <psockali> can i protected a memory page against write access in hurd
+ <psockali> and if so, is it a fast operation ?
+ <youpi> you can, I never measured, but it's probably the same cost as in
+ linux
+ <youpi> I don't see why it would be different, as it boils down to the same
+ x86 trick
+ <psockali> but i suppose it is part of the mach kernel doing the protection
+ and not part of the unix layer ?
+ <youpi> it is
+ <youpi> the unix layer doesn't have mm control
+ <youpi> it has to ask the kernel
+ <braunr> it's slower on mach, as it's less optimized because of historical
+ reasons
+ <braunr> but that's about it
+ <youpi> less optimized, how so?
+ <braunr> well, more entry fragmentation
+ <youpi> in the end you mark the page table and flush the tlb
+ <braunr> yes
+ <braunr> the high level virtual memory layer is a bit slower
+ <youpi> but fragmentation doesn't come into play it you just have one
+ memory object, does it?
+ <braunr> it does, as it's about memory areas, not objects
+ <braunr> the object is merely a backing store
+ <braunr> protection, inheritance, copy on write are all area (vm_map_entry)
+ attributes
+ <braunr> also, some operations affect all the address spaces where a
+ physical page is mapped
+ <braunr> although i think linux does the same thing as mach/bsd now
+ <youpi> but mprotect/munprotect doesn't, does it?
+ <braunr> no
+ <braunr> or perhaps by side effect, in some situations, i'm not sure
+ <braunr> i think it depends if the memory is shared between processes, but
+ i don't remember the details and can't think of a proper example right
+ now
+ <braunr> but anyway, "slower" here is negligible unless address spaces are
+ really huge and filled with lots of map entries
+ <braunr> psockali: why do you ask ?
+ <psockali> can i post a link here ?
+ <braunr> about what ?
+ <psockali> it's regarding azul / managed runtime initiative
+ <psockali> a GC for java
+ <braunr> why not
+ <braunr> although i don't see the point for now :)
+ <psockali> they have a custom MM management module for their GC as linux
+ kernel modul
+ <psockali> and i was wondering if mach would be any faster then linux in
+ that aspect
+ <psockali>
+ http://stackoverflow.com/questions/3358545/whats-actually-in-the-managed-runtime-initiatives-kernel-patches-and-jvm
+ <braunr> psockali: generally speaking, mach is slower than linux because of
+ its age and the fact it didn't receive as much attention and
+ microoptimization as linux did
+ <braunr> psockali: about this article, there is no reason mach would be
+ faster
diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
index d7804864..03614fae 100644
--- a/open_issues/multithreading.mdwn
+++ b/open_issues/multithreading.mdwn
@@ -354,6 +354,33 @@ Tom Van Cutsem, 2009.
[[hurd/libpager]].
+### IRC, freenode, #hurd, 2013-03-29
+
+ <braunr> some day i'd like to add a system call that threads can use to
+ terminate themselves, passing their stack as a parameter for deallocation
+ <braunr> then, we should review the timeouts used with libports management
+ <braunr> having servers go away when unneeded is a valuable and visible
+ feature of modularity
+
+
+### IRC, freenode, #hurd, 2013-04-03
+
+ <braunr> youpi: i also run without the libports_stability patch
+ <braunr> and i'd like it to be removed unless you still have a good reason
+ to keep it around
+ <youpi> well, the reason I know is mentioned in the patch
+ <youpi> i.e. the box becomes unresponsive when all these threads wake up at
+ the same time
+ <youpi> maybe we could just introduce some randomness in the sleep time
+ <braunr> youpi: i didn't experience the problem
+ <youpi> well, I did :)
+ <braunr> or if i did, it was very short
+ <youpi> for the libports stability, I'd really say take a random value
+ between timeout/2 and timeout
+ <youpi> and that should just nicely fix the issue
+ <braunr> ok
+
+
## Alternative approaches:
* <http://www.concurrencykit.org/>
diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn
index e27d3018..1f4c6ab8 100644
--- a/open_issues/nice_vs_mach_thread_priorities.mdwn
+++ b/open_issues/nice_vs_mach_thread_priorities.mdwn
@@ -387,3 +387,43 @@ here.
<youpi> the issue is mach not supporting enough sched levels
<youpi> can be fixed, of course
<youpi> just nobody did yet
+
+GNU Mach commit 6a234201081156e6d5742e7eeabb68418b518fad (and commit
+6fe36b76f7983ec9a2e8a70420e431d54252442e).
+
+
+## IRC, OFTC, #debian-hurd, 2013-03-07
+
+ <braunr> youpi: btw, why did you increase the number of priorites to 50 ?
+ <youpi> for the nice levels
+ <braunr> and probably something more, there are only 40 nice levels
+ <youpi> yes, the current computation leaves some margin
+ <youpi> so I preferred to keep a margin too
+ <braunr> ok
+ <youpi> e.g. for the idle thread, etc.
+ <braunr> or interrupt threads
+ <youpi> yep
+ <braunr> i see the point, thanks
+ <tschwinge> Is the number of 40 specified by POSIX (or whatever) or is that
+ a Linuxism?
+ <braunr> good question
+ <braunr> posix is weird when it comes to such old unixisms
+ <braunr> there is a NZERO value, but i don't remember how it's specified
+ <youpi> it's at least 20
+ <tschwinge> (I don't object to the change; just wondered. And if practice,
+ you probably wouldn't really need more than a handful. But if that
+ change (plus some follow-up in glibc (?) improves something while not
+ adding a lot of overhead, then that's entirely fine, of course.)
+ <braunr> "A maximum nice value of 2*{NZERO}-1 and a minimum nice value of 0
+ shall be imposed by the system"
+ <braunr> NZERO being 20 by default
+ <youpi> and 20 is the minimum for NZERO too
+ <braunr> hm, not the default, the minimul
+ <braunr> minimum
+ <braunr> yes that's it
+ <braunr> ok so it's actually well specified
+ <tschwinge> Aha, I see (just read it, too). So before that change we
+ simply couldn't satisfy the POSIX requirement of (minimum) NZERO = 20,
+ and allowing for step-1 increments. Alright.
+ <youpi> yep
+ <youpi> thus failing in coreutils testsuite
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn
index 8a8ba823..768dca93 100644
--- a/open_issues/performance/io_system/read-ahead.mdwn
+++ b/open_issues/performance/io_system/read-ahead.mdwn
@@ -2989,3 +2989,45 @@ License|/fdl]]."]]"""]]
determine what m_o_ function will be used
<mcsim> now default_read calls m_o_ on its own
<braunr> ok
+
+
+## IRC, freenode, #hurd, 2013-03-06
+
+ <mcsim> braunr: hi, regarding memory policies. Should I create separate
+ policy that will do pageout or VM_ADVICE_SEQUENTIAL is good enough?
+ <mcsim> braunr: at the moment it is exactly like NORMAL
+ <braunr> mcsim: i thought you only did pageins
+ <mcsim> braunr: yes, but I'm doing pageouts now
+ <braunr> oh
+ <braunr> i'd prefer you didn't :/
+ <braunr> if you want to improve paging, i have a suggestion i believe is a
+ lot better
+ <braunr> and we have 3 patches concerning libpager that we need to review,
+ polish, and merge in
+ <mcsim> braunr: That's not hard, and I think I know what to do
+ <braunr> yes i understand that
+ <braunr> but it may change the interface and conflict with the pending
+ changes
+ <mcsim> braunr: What changes?
+ <braunr> the large store patch, neal's libpager rework patch on top of
+ which you made your changes, and your changes
+ <braunr> the idea i have in mind was writeback throttling
+
+[[hurd/translator/ext2fs]], [[hurd/libpager]].
+
+ <braunr> i was planning on doing it myself but if you want to work on it,
+ feel free to
+ <braunr> it would be a much better improvement at this time than clustered
+ pageouts
+ <braunr> (which can then immediately follow
+ <braunr> )
+ <mcsim> braunr: ok
+ <mcsim> braunr: but this looks much more bigger task for me
+ <braunr> we'll talk about the strategy i had in mind tomorrow
+ <braunr> i hope you find it simple enough
+ <braunr> on the other hand, clustered pageouts are very similar to pageins
+ <braunr> and we have enough paging related changes to review that adding
+ another wouldn't be such a problem actually
+ <mcsim> so, add?
+ <braunr> if that's what you want to do, ok
+ <braunr> i'll think about your initial question tomorrow
diff --git a/open_issues/pfinet_timers.mdwn b/open_issues/pfinet_timers.mdwn
index 387ad4fe..5db192e3 100644
--- a/open_issues/pfinet_timers.mdwn
+++ b/open_issues/pfinet_timers.mdwn
@@ -15,3 +15,105 @@ License|/fdl]]."]]"""]]
<braunr> now that there is a pthread_hurd_cond_timedwait_np function
available, we could replace the ulgy timers in pfinet
+
+
+# IRC, freenode, #hurd, 2013-04-02
+
+ <braunr> youpi: also, i think i know why fakeroot is slow on the hurd
+ <braunr> well, pfinet actually
+ <youpi> tcp flow control?
+ <braunr> i think it's because of our timer resolution
+ <youpi> ah
+ <braunr> and i think i spotted a small mistake in the timer emulation code
+ btw
+ <braunr> it's so obvious i even doubt it's actually true :)
+ <braunr> see timer_emul.c:timer_function
+ <braunr> the code checks for timers->expires < jiffies
+ <braunr> shouldn't it be "<="
+ <braunr> ?
+ <youpi> well it'd be equivalent
+ <youpi> if ==, then wait becomes 0 in the else
+ <braunr> see the second scheck
+ <braunr> the one performed right before running the callback
+ <youpi> ah, the while?
+ <braunr> yes
+ <youpi> I'd say <= could do it yes
+ <braunr> ok
+ <braunr> i have hurd packages ready to be tested
+ <youpi> although I'm unsure it'd make a difference
+ <youpi> do you notice some?
+ <braunr> just waiting for my current glibc to finish building
+ <braunr> and i'll test right after
+ <braunr> i think it would actually
+ <youpi> in which case?
+ <braunr> the timer resolution is 10ms
+ <braunr> it's huge
+ <braunr> well, i hope it fixes fakeroot slowness :)
+ <youpi> so timers below that would trigger immediately?
+ <braunr> or equal
+ <braunr> taht's the problem
+ <braunr> for 10ms, timers that have expired must wait for the next tick to
+ fire
+ <youpi> I include "equal" in below
+ <youpi> actually :)
+ <braunr> then yes :)
+ <braunr> soryy i never know when equal is implicit
+ <youpi> because they boil down to expires = jiffies
+ <youpi> in french it's implicit
+ <youpi> but anyway here equal is not really important
+ <braunr> right
+ <braunr> why ?
+ <youpi> it's the fact that 1ms would be rounded up to 10ms, not down to 0ms
+ <braunr> well, doing that seems reasonable
+ <youpi> or rather, rounded down to 0ms, but waited for 10ms because of the
+ <
+ <braunr> we do want timers not to fire before the time event
+ <youpi> I'm however wondering which part of the code would have timer below
+ 10ms
+ <braunr> well, a select with low timeout from a client perhaps ?
+ <youpi> but then we have to round up
+ <youpi> as you say we don't want to fire before some time
+ <braunr> well yes
+ <braunr> that's fine
+ <youpi> all that being said, linux has been having 10ms clock for a long
+ time
+ <braunr> but when the timer fires, i.e. when expires == jiffie, we do want
+ it to fire
+ <youpi> highres timers are only relativeley recent
+ <braunr> not at jiffie + 1
+ <youpi> braunr: ah, right, so we don't wait for 20ms instead of 10ms
+ <braunr> yes
+ <youpi> ok, so it's not a miracle fix, but could bring 2times fix
+ <braunr> well, pfinet eats 40% of my processor when this problem occurs
+ <braunr> which i'm seeing right now
+ <youpi> yes, I've seen that too
+ <braunr> so it may be a visible win
+ <braunr> build finished :) let's see
+ <youpi> Mmm, thinking again
+ <youpi> indeed
+ <youpi> when expires become jiffies
+ <youpi> we mach_msg (0)
+ <youpi> but don't do anything
+ <youpi> and then restart
+ <youpi> so just eaten cpu for nothing
+ <braunr> is there a small package that builds fast and uses fakeroot a lot
+ ?
+ <youpi> something like a package which has a lot of data to install at make
+ install
+ <braunr> or i can rebuild glibc with -nc
+ <youpi> ok, I've checked in linux
+ <pinotree> libarchive's testsuite used to intermittently failing under
+ fakeroot
+ <youpi> it's definitely <= which is meant
+ <braunr> it looks better
+ <braunr> but still not 100% cpu
+ <youpi> at any rate, as long as it doesn't seem to break anything, please
+ push the fix
+ <youpi> it definitely makes sense
+ <youpi> (and I don't see why it could break anything)
+ <braunr> ok
+ <braunr> i'll look into this timer problem a bit more, there may be other
+ code involved
+ <braunr> yes, schedule_timeout could need a review
+ <braunr> actually, fakeroot rm -rf * is a good test
+ <braunr> and it's still damn slow
diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn
index bd9abcf9..0d786d2a 100644
--- a/open_issues/translate_fd_or_port_to_file_name.mdwn
+++ b/open_issues/translate_fd_or_port_to_file_name.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011, 2013 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,14 +16,17 @@ License|/fdl]]."]]"""]]
# IRC, freenode, #hurd, June (?) 2010
- <pochu> is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port?
+ <pochu> is there a way (POSIX or Hurdish) to get the corresponding file
+ name for a fd or a hurd port?
<marcusb> there is a way
<pochu> marcusb: which one would that be?
<marcusb> I forgot
<marcusb> there is an implementation in libc
<marcusb> realpath has a similar job
<marcusb> but that's not what I mean
- <marcusb> pochu: maybe I am misremembering. But it was something where you keep looking up .. and list that directory, looking for the node with the ID of the node you had .. for
+ <marcusb> pochu: maybe I am misremembering. But it was something where you
+ keep looking up .. and list that directory, looking for the node with the
+ ID of the node you had .. for
<marcusb> maybe it works only for directories
<marcusb> yeah
<marcusb> pochu: check the getcwd() implementation of libc
@@ -30,20 +34,25 @@ License|/fdl]]."]]"""]]
<marcusb> _hurd_canonicalize_directory_name_internal 
* pochu looks
<pochu> marcusb: interesting
- <pochu> though that is for dirs, and doesn't seem to be extensible to files, as you cannot lookup for ".." under a file
+ <pochu> though that is for dirs, and doesn't seem to be extensible to
+ files, as you cannot lookup for ".." under a file
<marcusb> right
<pochu> oh you already said that :)
<marcusb> actually, I am not sure that's correct
- <marcusb> it's probably correct, but there is no reason why looking .. up on a file couldn't return the directory it's contianed in
- <pochu> I don't know the interfaces or the Hurd internals very well yet, but it would look strange to me if you could do that
+ <marcusb> it's probably correct, but there is no reason why looking .. up
+ on a file couldn't return the directory it's contianed in
+ <pochu> I don't know the interfaces or the Hurd internals very well yet,
+ but it would look strange to me if you could do that
<marcusb> the hurd is strange
- <pochu> it sounds like if you could `ls getcwd.c/..` to get sysdeps/mach/hurd/ :-)
+ <pochu> it sounds like if you could `ls getcwd.c/..` to get
+ sysdeps/mach/hurd/ :-)
<marcusb> yep
<pochu> ok. interesting
<marcusb> you wouldn't find "ls foo.zip/.." very strange, wouldn't you?
<pochu> I guess not if `ls foo.zip` listed the contents of foo.zip
<marcusb> there you go
- <marcusb> or the other way round: would you be surprised if "cat somedir" would work?
+ <marcusb> or the other way round: would you be surprised if "cat somedir"
+ would work?
<pochu> I think so. if it did, what would it do?
<marcusb> originally, cat dir would list the directory content!
<marcusb> in the old unix times
@@ -51,10 +60,49 @@ License|/fdl]]."]]"""]]
<marcusb> and some early BSDs
* pochu feels young :-)
<marcusb> he don't worry, I didn't see those times either
- <marcusb> technically, files and directories are implemented in the same way in the hurd, they both are objects implementing the fs.defs interface
+ <marcusb> technically, files and directories are implemented in the same
+ way in the hurd, they both are objects implementing the fs.defs interface
<marcusb> which combines file and directory operations
- <marcusb> of course, files and directories implement those functions differently
- <antrik> marcusb: do you know why this behavior (cat on directories) was changed?
+ <marcusb> of course, files and directories implement those functions
+ differently
+ <antrik> marcusb: do you know why this behavior (cat on directories) was
+ changed?
+
+
+## IRC, freenode, #hurd, 2013-03-07
+
+ * pinotree ponders about sending as RFC his patch for /proc/$pid/maps
+ <tschwinge> Including a scheme for providing the names of mapped files?
+ ;-D
+ <braunr> that would be really great indeed
+ <tschwinge> I have not yet researched how Linux does this. Perhaps store
+ the filename used for first opening a file as a string somewhere?
+ <pinotree> tschwinge: eh, indeed that's lacking in my patch
+ <braunr> i'm not sure we should aim at doing it the same way
+ <youpi> I was wondering about having interfaces for naming tasks, threads,
+ objects
+ <youpi> that'd be useful for debugging in general
+ <braunr> yes
+ <braunr> i don't think we need to take namespaces into account
+ <braunr> a simple name or path should be quite enough
+ <tschwinge> Agreed. "Just something!"
+ <tschwinge> So, a Java toString() method for ports.
+ <tschwinge> ;-)
+ <braunr> yes
+ <tschwinge> Oh, and could this also work recursively? The ext2fs instance
+ on /home asks its parent fs about its own path -- can it do that? (And
+ then cache that, most likely?) Would one get rooted filesnames that way?
+ <braunr> i really don't think we should link it to the VFS
+ <braunr> it should merely be a name for debugging
+ <youpi> yep, same for me
+ <youpi> I'd say it's the linker's task of just setting a sane name
+ <braunr> first, keeping it isolated prevents increasing complexity
+ <braunr> next, it doesn't reduce performance
+ <tschwinge> youpi: Linker?
+ <tschwinge> braunr: Ack.
+ <braunr> yes, ld is the one creating the mappings
+ <youpi> tschwinge: the one that loads libraries
+ <tschwinge> Ah, for /proc/*/maps, right. I've been thinking more globally.
# IRC, freenode, #hurd, 2011-07-13
diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn
index ec762b59..f4739776 100644
--- a/open_issues/virtualization/fakeroot.mdwn
+++ b/open_issues/virtualization/fakeroot.mdwn
@@ -15,3 +15,10 @@ License|/fdl]]."]]"""]]
<youpi> btw, about fakeroot-hurd
<youpi> the remaining issue I see is with argv[0] (yes, again...)
+
+
+## IRC, freenode, #hurd, 2013-04-03
+
+ <youpi> btw, I believe our fakeroot-hurd is close to working actually
+ <youpi> it's just a argv[0] issue supposed to be fixed by exec_file_name
+ but apparently not fixed in that case, for some reason
diff --git a/open_issues/virtualization/remap_root_translator.mdwn b/open_issues/virtualization/remap_root_translator.mdwn
index 67d64ae0..dcef310d 100644
--- a/open_issues/virtualization/remap_root_translator.mdwn
+++ b/open_issues/virtualization/remap_root_translator.mdwn
@@ -139,3 +139,8 @@ License|/fdl]]."]]"""]]
<youpi> let me just comment out that :)
<youpi> way better :)
<youpi> yep, just works fine
+
+
+# IRC, freenode, #hurd, 2013-03-16
+
+ <braunr> youpi: is the /bin/remap --help output correct ?