Svante Signell, le Tue 06 Nov 2012 23:48:12 +0100, a écrit :
> First a question related to the io_select() call in
> eglibc-2.13/hurd/hurdselect.c. I was assuming that the corresponding
> S_io_select() implementation was from pflocal.c,
It depends what kind of fd you are selecting on. If it's a pipe, it'll
be pflocal ; if it's a tcp/ip socket, it'll be pfinet, etc. See
“How do I know which translator the RPC gets into?”
in rpc.mdwn.
> but adding print
> statements of trying to set a breakpoint in gdb does not hit that code.
> (And trying to step into the io_select() call in gdb makes it freeze).
Stepping in the io_select call will only see the client part of the
io_select RPC, not the server part. You have to determine yourself
which server will receive the RPC and gdb that one.
> 1) In hurd there are a number of *S_io_select() implementations, how to
> find which one is executed by the call in hurdselect.c?
Same as above.
> pflocal/io.c:S_io_select <- I assumed this was the one, right or wrong?
Depends on what kind of fd you're selecting on.
> My guess is that they are related to the mach interface, via MIG, to the
> the corresponding RPC_* files generated by the glibc build.
They are. The actual relation is made when you open the fd.
> Maybe I missed some of the definitions, never mind.
It DOES probably mind.
> a) How to find out if the translator is both passive and active:
> pflocal is a passive translator:
> #> showtrans /servers/socket/1
> /hurd/pflocal
> b) How to find out if there is also an active running?
I don't know how to check for active translator presence in all cases
(fsysopts isn't necessarily supported). Usually one simply checks in ps
whether the process is running.
> Killing the process containing /hurd/pflocal as suggested by Samuel on
> IRC freezes the ssh connection, break out from ssh
Well, yes, that kills all existing pipes.
> and log in again (or use the console) -> The passive translator starts
> again!
Sure, that's what a passive translator is made for.
> c) How to get rid of the active translator?
> #> settrans -f /servers/socket/1 ??
settrans /servers/socket/1
That will however have the same effect as killing the process.
> d) Trying to replace the old active translator without removing the old
> one:
> #> settrans -a /servers/socket/1 /hurd/pflocal.new
> settrans: /servers/socket/1: Device or resource busy
Yes, and see what tschwinge wrote for you on IRC:
“Even better may be to use settrans' --orphan option, but I have not
tested this.”
which indeed looks promising from --help:
-o, --orphan Disconnect old translator from the filesystem (do
not ask it to go away)
Samuel
