summaryrefslogtreecommitdiff
path: root/open_issues
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2013-07-11 15:45:57 -0400
committerThomas Schwinge <thomas@codesourcery.com>2013-07-11 15:53:52 -0400
commit65efe654a9cb0b682efa9bf21065469a2e9147f4 (patch)
tree07068fa2e54507756a239249fe894434c6920f27 /open_issues
parent3e3b91314fbdb9cead42b46ca8a0b5affcd7253a (diff)
parent9667351422dec0ca40a784a08dec7ce128482aba (diff)
Merge remote-tracking branch 'fp/master'
Diffstat (limited to 'open_issues')
-rw-r--r--open_issues/anatomy_of_a_hurd_system.mdwn217
-rw-r--r--open_issues/glibc.mdwn17
-rw-r--r--open_issues/gnumach_integer_overflow.mdwn35
-rw-r--r--open_issues/gnumach_vm_object_resident_page_count.mdwn28
-rw-r--r--open_issues/libmachuser_libhurduser_rpc_stubs.mdwn26
-rw-r--r--open_issues/open_symlink.mdwn14
-rw-r--r--open_issues/profiling.mdwn105
-rw-r--r--open_issues/sendmsg_scm_creds.mdwn77
-rw-r--r--open_issues/translate_fd_or_port_to_file_name.mdwn51
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 d45f0d14..31437744 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -1389,6 +1389,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: