From ef20dadf4b2dc498f99f3101cd17349339fb9354 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 29 Mar 2011 10:46:11 +0200 Subject: More from IRC. --- open_issues/inotify_file_notice_changes.mdwn | 42 ++++++++++++++++++++++ ...local_socket_credentials_for_local_sockets.mdwn | 42 ++++++++++++++++++++++ 2 files changed, 84 insertions(+) create mode 100644 open_issues/inotify_file_notice_changes.mdwn create mode 100644 open_issues/pflocal_socket_credentials_for_local_sockets.mdwn (limited to 'open_issues') 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]] + + 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? + barrucadu: In the Hurd spirit, you'd use file_notice_changes + (fs.defs). + thanks + we should manage to work out an inotify interface around it, btw + like gamin? + imho making gamin work should gain all the fam-using + applications + (which, looking at the sources, seems to support hurd already, not + sure why it's not built) + pochu: the hurd_notify of gamin does not build OOTB + > /build/buildd/gamin-0.1.10/./libgamin/gam_data.c:476: error: + 'PTHREAD_MUTEX_RECURSIVE' undeclared (first use in this function) + there are few patches in bugzilla to make it compile + if they work, and you point me to them, I can upload a new gamin + with them included + #315644, #588337. #605246 + and iirc there's something else i have locally but not send yet + please check and submit :) + ah no, those three contains all the build issues + .. plus relative proposed fixes + ok, I'll try to get to it soonish + and you should know about two of them already ;D + 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]] + + basically, i'm trying to implement socket credentials for local + sockets, and i guessed doing it in pflocal would be the appropriate place + what i thought was filling the cmsg data for MSG_CRED at + S_socket_recv() call + 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? + pinotree: that's needed by dbus right? cool! (and I don't know) + (yes, and gamin) + pinotree: you have them already, they're just not stored + see S_io_reauthenticate + Throw away the ids we went through all that trouble to get... + (comment) + * pinotree looks + hm, and who calls that rpc? + everybody + since that's how ext2fs knows the permission to apply, for instance + ah, i was referring to the reauthenticate of pflocal, not + auth_server_authenticate() + that's what I'm saying + see __hurd_file_name_lookup_retry, which is the very internal part + of open() + it calls io_reauthenticate() + to authenticate itself to the underlying translator of the opened + node + youpi: so, hm, could be an option make the result of pflocal's + S_io_reauthenticate cached in the sock_user struct? + yes + nice thanks, i will try that change first -- cgit v1.2.3