Re: (still) Need some help with translators

[Samuel Thibault]

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