More from IRC.

2 files changed, 84 insertions, 0 deletions

diff --git a/open_issues/inotify_file_notice_changes.mdwn b/open_issues/inotify_file_notice_changes.mdwn
new file mode 100644
index 00000000..a30cd3d3
--- /dev/null
+++ b/open_issues/inotify_file_notice_changes.mdwn
@@ -0,0 +1,42 @@
+[[!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-03-28
+
+[[!tag open_issue_hurd]]
+
+    <barrucadu> I've been going through the xmlfs code, and plan to have it
+      monitor the backing store (xml file) for changes and update the presented
+      directory hierarchy when something is changed; is there a better way to
+      check a file for changes beyond checking its modification time every few
+      minutes?
+    <tschwinge> barrucadu: In the Hurd spirit, you'd use file_notice_changes
+      (fs.defs).
+    <barrucadu> thanks
+    <youpi> we should manage to work out an inotify interface around it, btw
+    <pochu> like gamin?
+    <pinotree> imho making gamin work should gain all the fam-using
+      applications
+    <pochu> (which, looking at the sources, seems to support hurd already, not
+      sure why it's not built)
+    <pinotree> pochu: the hurd_notify of gamin does not build OOTB
+    <pochu> > /build/buildd/gamin-0.1.10/./libgamin/gam_data.c:476: error:
+      'PTHREAD_MUTEX_RECURSIVE' undeclared (first use in this function)
+    <pinotree> there are few patches in bugzilla to make it compile
+    <pochu> if they work, and you point me to them, I can upload a new gamin
+      with them included
+    <pinotree> #315644, #588337. #605246
+    <pinotree> and iirc there's something else i have locally but not send yet
+    <pochu> please check and submit :)
+    <pinotree> ah no, those three contains all the build issues
+    <pinotree> .. plus relative proposed fixes
+    <pochu> ok, I'll try to get to it soonish
+    <pinotree> and you should know about two of them already ;D
+    <pochu> please remind me if I don't :)
diff --git a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn
new file mode 100644
index 00000000..5a71412e
--- /dev/null
+++ b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn
@@ -0,0 +1,42 @@
+[[!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-03-28
+
+[[!tag open_issue_hurd]]
+
+    <pinotree> basically, i'm trying to implement socket credentials for local
+      sockets, and i guessed doing it in pflocal would be the appropriate place
+    <pinotree> what i thought was filling the cmsg data for MSG_CRED at
+      S_socket_recv() call
+    <pinotree> in case i missed it, would there be a way to "identify" the
+      other side of the port associated to the sock_user of that call?
+    <pochu> pinotree: that's needed by dbus right? cool! (and I don't know)
+    <pinotree> (yes, and gamin)
+    <youpi> pinotree: you have them already, they're just not stored
+    <youpi> see S_io_reauthenticate
+    <youpi> Throw away the ids we went through all that trouble to get...
+    <youpi> (comment)
+    * pinotree looks
+    <pinotree> hm, and who calls that rpc?
+    <youpi> everybody
+    <youpi> since that's how ext2fs knows the permission to apply, for instance
+    <pinotree> ah, i was referring to the reauthenticate of pflocal, not
+      auth_server_authenticate()
+    <youpi> that's what I'm saying
+    <youpi> see __hurd_file_name_lookup_retry, which is the very internal part
+      of open()
+    <youpi> it calls io_reauthenticate()
+    <youpi> to authenticate itself to the underlying translator of the opened
+      node
+    <pinotree> youpi: so, hm, could be an option make the result of pflocal's
+      S_io_reauthenticate cached in the sock_user struct?
+    <youpi> yes
+    <pinotree> nice thanks, i will try that change first