summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--open_issues/inotify_file_notice_changes.mdwn42
-rw-r--r--open_issues/pflocal_socket_credentials_for_local_sockets.mdwn42
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