IRC.

9 files changed, 564 insertions, 6 deletions

diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index 677e4625..11a1f754 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -380,3 +380,220 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
     <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
+
+
+# IRC, freenode, #hurd, 2013-05-23
+
+    <gnu_srs> Hi, is there any efficient way to control which backed
+      translators are called via RPC with a user space program?
+    <gnu_srs> Take for example io_stat: S_io_stat is defined in boot/boot.c,
+      pfinet/io-ops.c and pflocal/io.c
+    <gnu_srs> And the we have libdiskfs/io-stat.c:diskfs_S_io_stat,
+      libnetfs/io-stat.c:netfs_S_io_stat, libtreefs/s-io.c:treefs_S_io_stat,
+      libtrivfs/io-stat.c:trivfs_S_io_stat
+    <gnu_srs> How are they related?
+    <braunr> gnu_srs: it depends on the server (translator) managing the files
+      (nodes) you're accessing
+    <braunr> so use fsysopts to know the server, and see what this server uses
+    <gnu_srs> fsysopts /hurd/pfinet and fsysopts /hurd/pflocal gives the same
+      answer: ext2fs --writable --no-inherit-dir-group --store-type=typed
+      device:hd0s1
+    <braunr> of course
+    <braunr> the binaries are regular files
+    <braunr> see /servers/socket/1 and /servers/socket/2 instead
+    <braunr> which are the nodes representing the *service*
+    <braunr> again, the hurd uses the file system as a service directory
+    <braunr> this usage of the file system is at the core of the hurd design
+    <braunr> files are not mere files, they're service names
+    <braunr> it happens that, for most files, the service behind them is the
+      same as for regular files
+    <braunr> gnu_srs: this *must* be obvious for you to do any tricky work on
+      the hurd
+    <gnu_srs> fsysopts /servers/socket/2 works by /1 gives Operation not
+      supported.
+
+[[!taglink open_issue_hurd]].
+
+    <braunr> ah right, some servers don't implement that
+    <braunr> work around this by using showtrans
+    <braunr> fsysopts asks the server itself how it's running, usually giving
+      its command name and options
+    <braunr> showtrans asks the parent how it starts a passive translator
+      attached to the node
+    <gnu_srs> Yes showtrans works :), thanks.
+    <gnu_srs> Anyway, if I create a test program calling io_stat I assume
+      S_io_stat in pflocal is called.
+    <gnu_srs> How to make the program call S_io_stat in pfinet instead? 
+    <braunr> create a socket managed by pfinet
+    <braunr> i.e. an inet or inet6 socket
+    <braunr> you can't assume io_stat is serviced by pflocal
+    <braunr> only stats on unix sockets of pipes will be
+    <braunr> or*
+    <gnu_srs> thanks, what about the *_S_io_stat functions?
+    <braunr> what about them ?
+    <gnu_srs> How they fit into the picture, e.g. diskfs_io_stat?
+    <gnu_srs> *diskfs_S_io_stat
+    <braunr> gnu_srs: if you open a file managed by a server using libdiskfs,
+      e.g. ext2fs, that one will be called
+    <gnu_srs> Using the same user space call: io_stat, right?
+    <braunr> it's all userspace
+    <braunr> say rather, client-side
+    <braunr> the client calls the posix stat() function, which is implemented
+      by glibc, which converts it into a call to io_stat, and sends it to the
+      server managing the open file
+    <braunr> the io_stat can change depending on the server
+    <braunr> the remote io_stat implementation, i mean
+    <braunr> identify the server, and you will identify the actual
+      implementation
+
+
+# IRC, freenode, #hurd, 2013-06-15
+
+    <damo22> ive been reading a little about exokernels or unikernels, and i
+      was wondering if it might be relevant to the GNU/hurd design.  I'm not
+      too familiar with hurd terminology so forgive me.  what if every
+      privileged service was compiled as its own mini "kernel" that handled (a)
+      any hardware related to that service (b) any device nodes exposed by that
+      service etc...
+    <braunr> yes but not really that way
+    <damo22> under the current hurd model of the operating system, how would
+      you talk to hardware that required specific timings like sound hardware?
+    <braunr> through mapped memory
+    <damo22> is there such a thing as an interrupt request in hurd?
+    <braunr> obviously
+    <damo22> ok
+    <damo22> is there any documentation i can read that involves a driver that
+      uses irqs for hurd?
+    <braunr> you can read the netdde code
+    <braunr> dde being another project, there may be documentation about it
+    <braunr> somewhere else
+    <braunr> i don't know where
+    <damo22> thanks
+    <damo22> i read a little about dde, apparently it reuses existing code from
+      linux or bsd by reimplementing parts of the old kernel like an api or
+      something
+    <braunr> yes
+    <damo22> it must translate these system calls into ipc or something
+    <damo22> then mach handles it?
+    <braunr> exactly
+    <braunr> that's why i say it's not the exokernel way of doing things
+    <damo22> ok
+    <damo22> so does every low level hardware access go through mach?'
+    <braunr> yes
+    <braunr> well no
+    <braunr> interrupts do
+    <braunr> ports (on x86)
+    <braunr> everything else should be doable through mapped memory
+    <damo22> seems surprising that the code for it is so small
+    <braunr> 1/ why surprising ? and 2/ "so small" ?
+    <damo22> its like the core of the OS, and yet its tiny compared to say the
+      linux kernel
+    <braunr> it's a microkenrel
+    <braunr> well, rather an hybrid
+    <braunr> the size of the equivalent code in linux is about the same
+    <damo22> ok
+    <damo22> with the model that privileged instructions get moved to
+      userspace, how does one draw the line between what is OS and what is user
+      code
+    <braunr> privileged instructions remain in the kernel
+    <braunr> that's one of the few responsibilities of the kernel
+    <damo22> i see, so it is an illusion that the user has privilege in a sense
+    <braunr> hum no
+    <braunr> or, define "illusion"
+    <damo22> well the user can suddenly do things never imaginable in linux
+    <damo22> that would have required sudo
+    <braunr> yes
+    <braunr> well, they're not unimaginable on linux
+    <braunr> it's just not how it's meant to work
+    <damo22> :)
+    <braunr> and why things like fuse are so slow
+    <braunr> i still don't get "i see, so it is an illusion that the user has
+      privilege in a sense"
+    <damo22> because the user doesnt actually have the elevated privilege its
+      the server thing (translator)?
+    <braunr> it does
+    <braunr> not at the hardware level, but at the system level
+    <braunr> not being able to do it directly doesn't mean you can't do it
+    <damo22> right
+    <braunr> it means you need indirections
+    <braunr> that's what the kernel provides
+    <damo22> so the user cant do stuff like outb 0x13, 0x1
+    <braunr> he can
+    <braunr> he also can on linux
+    <damo22> oh
+    <braunr> that's an x86 specifity though
+    <damo22> but the user would need hardware privilege to do that
+    <braunr> no
+    <damo22> or some kind of privilege
+    <braunr> there is a permission bitmap in the TSS that allows userspace to
+      directly access some ports
+    <braunr> but that's really x86 specific, again
+    <damo22> i was using it as an example
+    <damo22> i mean you wouldnt want userspace to directly access everything
+    <braunr> yes
+    <braunr> the only problem with that is dma reall
+    <braunr> y
+    <braunr> because dma usually access physical memory directly
+    <damo22> are you saying its good to let userspace access everything minus
+      dma?
+    <braunr> otherwise you can just centralize permissions in one place (the
+      kernel or an I/O server for example)
+    <braunr> no
+    <braunr> you don't let userspace access everything
+    <damo22> ah
+    <damo22> yes
+    <braunr> userspace asks for permission to access one specific part (a
+      memory range through mapping)
+    <braunr> and can't access the rest (except through dma)
+    <damo22> except through dma??  doesnt that pose a large security threat?
+    <braunr> no
+    <braunr> you don't give away dma access to anyone
+    <braunr> only drivers
+    <damo22> ahh
+    <braunr> and drivers are normally privileged applications anyway
+    <damo22> so a driver runs in userspace?
+    <braunr> so the only effect is that bugs can affect other address spaces
+      indirectly
+    <braunr> netdde does
+    <damo22> interesting
+    <braunr> and they all should but that's not the case for historical reasons
+    <damo22> i want to port ALSA to hurd userspace :D
+    <braunr> that's not so simple unfortunately
+    <braunr> one of the reasons it's hard is that pci access needs arbitration
+    <braunr> and we don't have that yet
+    <damo22> i imagine that would be difficult
+    <braunr> yes
+    <braunr> also we're not sure we want alsa
+    <braunr> alsa drivers, maybe, but probably not the interface itself
+    <damo22> its tangled spaghetti
+    <damo22> but the guy who wrote JACK for audio hates OSS, and believes it is
+      rubbish due to the fact it tries to read and write to a pcm device node
+      like a filesystem with no care for timing
+    <braunr> i don't know audio well enough to tell you anything about that
+    <braunr> was that about oss3 or oss4 ?
+    <braunr> also, the hurd isn't a real time system
+    <braunr> so we don't really care about timings
+    <braunr> but with "good enough" latencies, it shouldn't be a problem
+    <damo22> but if the audio doesnt reach the sound card in time, you will get
+      a crackle or a pop or a pause in the signal
+    <braunr> yep
+    <braunr> it happens on linux too when the system gets some load
+    <damo22> some users find this unnacceptable
+    <braunr> some users want real time systems
+    <braunr> using soft real time is usually plenty enough to "solve" this kind
+      of problems
+    <damo22> will hurd ever be a real time system?
+    <braunr> no idea
+    <youpi> if somebody works on it why not
+    <youpi> it's the same as linux
+    <braunr> it should certainly be simpler than on linux though
+    <damo22> hmm
+    <braunr> microkernels are well suited for real time because of the well
+      defined interfaces they provide and the small amount of code running in
+      kernel
+    <damo22> that sounds promising
+    <braunr> you usually need to add priority inheritance and take care of just
+      a few corner cases and that's all
+    <braunr> but as youpi said, it still requires work
+    <braunr> and nobody's working on it
+    <braunr> you may want to check l4 fiasco.oc though
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index 33a1a071..b06b4f9f 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -1305,6 +1305,23 @@ Failures, mostly in order of appearance:
 
     Due to `ext2fs --no-atime`.
 
+      * IRC, OFTC, #debian-hurd, 2013-05-08
+
+            <youpi> bah, tst-atime failure :)
+            <pinotree> do you have its output?
+            <youpi> well it's very simple
+            <youpi> I have the noatime option on / :)
+            <pinotree> oh
+            <youpi> fortunately fsysopts works :)
+            <pinotree> the test checks whether ST_NOATIME is in the mount
+              options, maybe it would be a good idea to provide it
+            <youpi> yes
+            <pinotree> unfortunately it isn't in posix, so i'm not sure whether
+              adding it to the general bits/statvfs.h would be welcome
+            <pinotree> or whether we should fork it, like it is done for linux 
+            <pinotree> oh no, we fork it already
+            <pinotree> \o/
+
     `dirent/tst-fdopendir.out`:
 
         directory atime changed
diff --git a/open_issues/gnumach_integer_overflow.mdwn b/open_issues/gnumach_integer_overflow.mdwn
index 2166e591..08a29268 100644
--- a/open_issues/gnumach_integer_overflow.mdwn
+++ b/open_issues/gnumach_integer_overflow.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -15,3 +15,36 @@ License|/fdl]]."]]"""]]
 
     <braunr> yes, we have integer overflows on resident_page_count, but
       luckily, the member is rarely used
+
+See also [[gnumach_vm_object_resident_page_count]].
+
+
+## IRC, freenode, #hurd, 2013-06-04
+
+    <elmig> this is declared as int on vm_object.h
+    <elmig> and as it as counter it's always positive
+    <braunr> yes it should be unsigned
+    <elmig> ok
+    <braunr> but leave it as it is for consistency with the rest
+    <elmig> i send patch :)
+    <braunr> please no
+    <braunr> unless you've fully determined the side effects
+    <elmig> i've grepped the vars and saw only comparisons > and = 0
+    <elmig> never less than 0
+    <braunr> > 0 is the same
+    <braunr> well
+    <braunr> > not, but >= would be a problem
+    <elmig> http://paste.debian.net/plain/8527
+    <elmig> asctually no >=0
+    <braunr> still, i don't want to change that unless it's strictly necessary
+    <braunr> hum, you're grepping ref_count, not resident_page_count
+    <elmig> i did both
+    <elmig> on resident_page_count theres resident_page_count >= 0
+    <elmig> = 0, == 0
+    <braunr> this isn't the only possible issue
+    <braunr> anyway
+    <braunr> for now there is no reason to change anything unless you do a full
+      review
+    <elmig> only place i see resdent_page_count and page_count being decreased
+      it's on vm/vm_resident.c
+    <elmig> vm_page_remove() and vm_page_replace()
diff --git a/open_issues/gnumach_vm_object_resident_page_count.mdwn b/open_issues/gnumach_vm_object_resident_page_count.mdwn
index cc1b8897..5c1247b2 100644
--- a/open_issues/gnumach_vm_object_resident_page_count.mdwn
+++ b/open_issues/gnumach_vm_object_resident_page_count.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -20,3 +20,29 @@ License|/fdl]]."]]"""]]
     <braunr> luckily, this should be easy to solve
 
 `vm/vm_object.h:vm_object:resident_page_count`.
+
+
+## IRC, freenode, #hurd, 2013-06-03
+
+    <elmig> regarding
+      https://www.gnu.org/software/hurd/open_issues/gnumach_vm_object_resident_page_count.html,
+      this is fixed. it's an int. what should happen do this page? /dev/null
+    <elmig> ?
+    <youpi> I guess so
+
+
+## IRC, freenode, #hurd, 2013-06-04
+
+    <elmig>
+      http://darnassus.sceen.net/~hurd-web/open_issues/gnumach_vm_object_resident_page_count/
+    <elmig> this is a int
+    <elmig> how to deal with the page? delete it? archive it?
+    <braunr> ?
+    <elmig> the issue originallu reported was fixed, right?
+    <braunr> i think so, yes
+    <braunr> for now at least
+    <elmig> so this stays on the open_issues on the wiki anyway?
+    <braunr> no, it should go away
+    <elmig> i dont know how to suggest deletion on the wiki
+    <braunr> don't
+    <braunr> i'll do it later
diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
index 670c82cb..11bebd6e 100644
--- a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
+++ b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
@@ -133,3 +133,29 @@ License|/fdl]]."]]"""]]
     <braunr> (imo, the mach_debug interface should be adjusted to be used with
       privileged ports only)
     <braunr> (well, maybe not all mach_debug RPCs)
+
+
+# `gnumach.defs`
+
+[[!message-id
+"CAEvUa7nd2LSUsMG9axCx5FeaD1aBvNxE4JMBe95b9hbpdqiLdw@mail.gmail.com"]].
+
+
+## IRC, freenode, #hurd, 2013-05-13
+
+    <braunr> youpi: what's the point of the last commit in the upstream hurd
+      repository (utils/vmstat: Use gnumach.defs from gnumach) ?
+    <braunr> or rather, i think i see the point, but then why do it only for
+      gnumach and not fot the rest ?
+    <braunr> for*
+    <youpi> most probably because nobody did it, probably
+    <braunr> aiui, it makes the hurd build process not rely on system headers
+    <youpi> (and nobody had any issue with it)
+    <braunr> well yes, that's why i'm wondering :)
+    <braunr> it looks perfectly fine to me to use system headers instead of
+      generating them
+    <youpi> ah right
+    <youpi> I thought there was actually a reason
+    <youpi> I'll revert
+    <youpi> could you answer David about it?
+    <braunr> sure
diff --git a/open_issues/open_symlink.mdwn b/open_issues/open_symlink.mdwn
index 20e4a4fe..f71109a9 100644
--- a/open_issues/open_symlink.mdwn
+++ b/open_issues/open_symlink.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -10,9 +10,21 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_glibc]]
 
+
 # IRC, freenode, #hurd, 2012-01-02
 
     <pinotree> hm, is it a known issue that open("somesymlink", O_RDONLY |
       O_NOFOLLOW) does not fail with ELOOP?
     <youpi> pinotree: iirc there is code for it, maybe not the same behavior as
       on linux
+
+
+## IRC, OFTC, #debian-hurd, 2013-05-08
+
+    <pinotree> the hurd issue is that Q_NOFOLLOW seems broken on symlinks, and
+      thus open(symlink, O_NOFOLLOW) doesn't fail with ELOOP
+    <youpi> I don't really see why it should fail
+    <youpi> since NOFOLLOW says not to follow the symlink
+    <pinotree> yeah, but you cannot open a symlink
+    <youpi> ah right ok
+    <youpi> interesting :)
diff --git a/open_issues/profiling.mdwn b/open_issues/profiling.mdwn
index 26e6c97c..545edcf6 100644
--- a/open_issues/profiling.mdwn
+++ b/open_issues/profiling.mdwn
@@ -9,10 +9,14 @@ 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="Profiling, Tracing"]]
+
 *Profiling* ([[!wikipedia Profiling_(computer_programming) desc="Wikipedia
 article"]]) is a tool for tracing where CPU time is spent.  This is usually
 done for [[performance analysis|performance]] reasons.
 
+  * [[hurd/debugging/rpctrace]]
+
   * [[gprof]]
 
     Should be working, but some issues have been reported, regarding GCC spec
@@ -33,3 +37,104 @@ done for [[performance analysis|performance]] reasons.
   * [[SystemTap]]
 
   * ... or some other Linux thing.
+
+
+# IRC, freenode, #hurd, 2013-06-17
+
+    <congzhang> is that possible we develop rpc msg analyse tool? make it clear
+      view system at different level?
+    <congzhang> hurd was dynamic system, how can we just read log line by line
+    <kilobug> congzhang: well, you can use rpctrace and then analyze the logs,
+      but rpctrace is quite intrusive and will slow down things (like strace or
+      similar)
+    <kilobug> congzhang: I don't know if a low-overhead solution could be made
+      or not
+    <congzhang> that's the problem
+    <congzhang> when real system run, the msg cross different server, and then
+      the debug action should not intrusive the process itself
+    <congzhang> we observe the system and analyse os
+    <congzhang> when rms choose microkernel, it's expect to accelerate the
+      progress, but not
+    <congzhang> microkernel make debug a litter hard
+    <kilobug> well, it's not limited to microkernels, debugging/tracing is
+      intrusive and slow things down, it's an universal law of compsci
+    <kilobug> no, it makes debugging easier
+    <congzhang> I don't think so
+    <kilobug> you can gdb the various services (like ext2fs or pfinet) more
+      easily
+    <kilobug> and rpctrace isn't any worse than strace
+    <congzhang> how easy when debug lpc
+    <kilobug> lpc ?
+    <congzhang> because cross context
+    <congzhang> classic function call
+    <congzhang> when find the bug source, I don't care performance, I wan't to
+      know it's right or wrong by design, If it work as I expect 
+    <congzhang> I optimize it latter
+    <congzhang> I have an idea, but don't know weather it's usefull or not
+    <braunr> rpctrace is a lot less instrusive than ptrace based tools
+    <braunr> congzhang: debugging is not made hard by the design choice, but by
+      implementation details
+    <braunr> as a simple counter example, someone often cited usb development
+      on l3 being made a lot easier than on a monolithic kernel
+    <congzhang> Collect the trace information first, and then layout the msg by
+      graph, when something wrong, I focus the trouble rpc, and found what
+      happen around
+    <braunr> "by graph" ?
+    <congzhang> yes
+    <congzhang> braunr: directed graph or something similar
+    <braunr> and not caring about performance when debugging is actually stupid
+    <braunr> i've seen it on many occasions, people not being able to use
+      debugging tools because they were far too inefficient and slow
+    <braunr> why a graph ?
+    <braunr> what you want is the complete trace, taking into account cross
+      address space boundaries
+    <congzhang> yes
+    <braunr> well it's linear
+    <braunr> switching server
+    <congzhang> by independent process view it's linear
+    <congzhang> it's linear on cpu's view too
+    <congzhang> yes, I need complete trace, and dynamic control at microkernel
+      level
+    <congzhang> os, if server crash, and then I know what's other doing, from
+      the graph
+    <congzhang> graph needn't to be one, if the are not connect together, time
+      sort them
+    <congzhang> when hurd was complete ok, some tools may be help too
+    <braunr> i don't get what you want on that graph
+    <congzhang> sorry, I need a context
+    <congzhang> like uml sequence diagram, I need what happen one by one
+    <congzhang> from server's view and from the function's view
+    <braunr> that's still linear
+    <braunr> so please stop using the word graph
+    <braunr> you want a trace
+    <braunr> a simple call trace
+    <congzhang> yes, and a tool
+    <braunr> with some work gdb could do it
+    <congzhang> you mean under  some microkernel infrastructure help 
+    <congzhang> ?
+    <braunr> if needed
+    <congzhang> braunr: will that be easy?
+    <braunr> not too hard
+    <braunr> i've had this idea for a long time actually
+    <braunr> another reason i insist on migrating threads (or rather, binding
+      server and client threads)
+    <congzhang> braunr: that's  great
+    <braunr> the current problem we have when using gdb is that we don't know
+      which server thread is handling the request of which client
+    <braunr> we can guess it
+    <braunr> but it's not always obvious
+    <congzhang> I read the talk, know some of your idea
+    <congzhang> make things happen like classic kernel, just from function
+      ,sure:)
+    <braunr> that's it
+    <congzhang> I think you and other do a lot of work to improve the mach and
+      hurd, buT we lack the design document and the diagram, one diagram was
+      great than one thousand words
+    <braunr> diagrams are made after the prototypes that prove they're doable
+    <braunr> i'm not a researcher
+    <braunr> and we have little time
+    <braunr> the prototype is the true spec
+    <congzhang> that's why i wan't cllector the trace info and show, you can
+      know what happen and how happen, maybe just suitable for newbie, hope
+      more young hack like it
+    <braunr> once it's done, everything else is just sugar candy around it
diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn
index cf0103df..d4a6126e 100644
--- a/open_issues/sendmsg_scm_creds.mdwn
+++ b/open_issues/sendmsg_scm_creds.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
+[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -11,7 +11,8 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_glibc]]
 
-IRC, unknown channel, unknown date.
+
+# IRC, unknown channel, unknown date
 
     <pinotree> Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2722
     <pinotree> 2722: Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2724
@@ -91,10 +92,80 @@ IRC, unknown channel, unknown date.
     <pinotree> yep
     <youpi> ok, good :)
 
-/!\ IRC, freenode, #hurd, 2011-08-11
+
+## IRC, freenode, #hurd, 2011-08-11
 
     < pinotree> (but that patch is lame)
 
+
+## IRC, freenode, #hurd, 2013-05-09
+
+    <gnu_srs> youpi: Since you are online tonight, which authentication
+      callbacks to be used for SCM_CREDS calls. 
+    <gnu_srs> I have working code and need to add this to make things
+      complete. The auth server, lib* or where?  
+    <youpi> I don't understand the question
+    <gnu_srs> authentication callbacks like for SCM_RIGHTS, see 
+    <gnu_srs>
+      http://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html
+    <youpi> I still don't understand: what are you trying to do actually?
+    <gnu_srs> solving the SCM_CREDS propbems with e.g. dbus.
+    <youpi> so what is the relation with pinotree's patch on the page above?
+    <youpi> (I have no idea of the current status of all that)
+    <gnu_srs> his patch was not merged, right? have to shut down, sorry, bbl,
+      gn8
+    <pinotree> that patch was not merged since it is not in the correct place
+    <youpi> as I said, I have no idea about the status
+    <pinotree> youpi: basically, it boils down to knowing, when executing the
+      code implementing an rpc, who requested that rpc (pid, uid, gid)
+    <youpi> i.e. getting information about the reply port for instance?
+    <youpi> well that might be somehow faked
+    <youpi> (by perhaps giving another task's port as reply port)
+    <pinotree> for example (which would be the code path for SCM_CREDS), when
+      you call call the socket sendmsg(), pflocal would know who did that rpc
+      and fill the auxilliary data)
+    <pinotree> s,)$,,
+    <pinotree> youpi: yes, i know about this faking issue, iirc also antrik
+      mentioned quite some time ago
+    <youpi> ok
+    <pinotree> that's one of the (imho) two issues of this
+    <pinotree> my hurd-foo is not enough to know whether there are solutions to
+      the problem above
+
+
+### IRC, freenode, #hurd, 2013-05-14
+
+    <gnu_srs> Hi, regarding SCM_CREDS, I have some working code in
+      sendmsg.c. Now I need to make a callback to authenticate the pid, uid,
+      etc
+    <gnu_srs> Where to hook call that into pflocal? 
+    <gnu_srs> the auth server?
+    <gnu_srs> maybe _io_restrict_auth is the correct call to use (same as for
+      SCM_RIGHTS)?
+
+
+### IRC, freenode, #hurd, 2013-05-17
+
+    <gnu_srs> I'm working on the scm credentials right now to enable (via dbus)
+      more X window managers to work properly.
+    <gnu_srs> seems to be rather tricky:-(
+    <pochu> gnu_srs: I guess you also need SCM_CREDS, right?
+    <gnu_srs> hi pochu, that's what I'm working on, extending your SCM_RIGHTS
+      work to SCM_CREDS
+    <pinotree> that's what i did as proof, years ago?
+    <gnu_srs> it would be good to know which server calls to make, I'll be back
+      with proposals of functions to use.
+    <pinotree> there was a talk, years ago when i started with this, and few
+      days ago too
+    <pinotree> every methods has its own drawbacks, and basically so far it
+      seems that in every method the sender identity can be faked somehow
+    <gnu_srs> pinotree: Yes of course your patch was perfect, but it seemed
+      like people wanted a server acknowledgement too.
+    <pinotree> no, my patch was not perfect at all
+    <pinotree> if it was, it would have been cleaned up and sent few years ago
+      already
+
+
 ---
 
 See also [[dbus]], [[pflocal_socket_credentials_for_local_sockets]] and
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 0d786d2a..0d6a460c 100644
--- a/open_issues/translate_fd_or_port_to_file_name.mdwn
+++ b/open_issues/translate_fd_or_port_to_file_name.mdwn
@@ -105,6 +105,57 @@ License|/fdl]]."]]"""]]
     <tschwinge> Ah, for /proc/*/maps, right.  I've been thinking more globally.
 
 
+## task_get_name, task_set_name RPCs
+
+[[!message-id "518AA5B0.6030409@verizon.net"]]
+
+
+## IRC, freenode, #hurd, 2013-05-10
+
+    <youpi> tschwinge's suggestion to put names on ports instead of tasks would
+      be useful too
+    <braunr> do you get task ports as easily as you get tasks in kdb ?
+    <youpi> there is task->itk_self & such
+    <youpi> or itk_space
+    <youpi> I don't remember which one is used by userspace
+    <braunr> i mean
+    <braunr> when you use the debugger, can you easily find its ports ?
+    <braunr> the task ports i mean
+    <braunr> or thread ports or whatever
+    <youpi> once you have a task, it's a matter of getting the itk_self port
+    <youpi> s/port/field member/
+    <braunr> so the debugger provides you with the addresses of the structs
+    <braunr> right ?
+    <youpi> yes, that's what we have already
+    <braunr> then ok
+    <braunr> bddebian: do that :p
+    <braunr> hehe
+    <youpi> see show all thread
+    <braunr> (haven't used kdb in a long time)
+    <bddebian> So, adding a name to ports like I did with tasks?
+    <braunr> remove what you did for tasks
+    <braunr> move it to ports
+    <braunr> it's very similar
+    <braunr> but hm
+    <braunr> i'm not sure where the RPC would be
+    <braunr> this RPC would exist for *all* ports
+    <braunr> or only for kernel objects if added to gnumach.defs
+    <youpi> it's just about moving the char array field to another structure
+    <youpi> and plugging that
+    <bddebian> But mach_task_self is a syscal, it looks like itk_self is just a
+      pointer to an ipc_port ?
+    <braunr> so ?
+    <braunr> you take that pointer and you get the port
+    <braunr> just like vm_map gets a struct vm_map from a task
+    <bddebian> So I am just adding ipc_port_name to the ipc_port struct in this
+      case?
+    <braunr> yes
+    <braunr> actually
+    <braunr> don't do anything just yet
+    <braunr> we need to sort a few details out first
+    <braunr> see bug-hurd
+
+
 # IRC, freenode, #hurd, 2011-07-13
 
 A related issue: