Unix FD Passing

[Thiago Macieira]

Em Terça-feira 05 Maio 2009, às 16:18:43, Lennart Poettering escreveu:
> On Tue, 05.05.09 08:42, Thiago Macieira (thiago at kde.org) wrote:
> > Lennart Poettering wrote:
> > >This is a local transport after all. There are processors which can be
> > >configured to run in either LE or BE mode, but AFAIK there is no OS
> > >that actually allows running processes in LE and BE side-by-side.
> >
> > Linux on IA-64 (Itanium).
>
> You say Itanium can do BE?

Yes. HP-UXi runs on Itanium by default on big endian mode. Linux runs by 
default on little-endian mode. But the Linux kernel has code to switch to 
little-endian mode when entering kernel mode:

http://lxr.linux.no/linux+v2.6.29/arch/ia64/kernel/gate.S#L80
	"rsm psr.be" reads "reset system mask" "processor status register" "big 
endian"

In theory, an application could switch at run-time from little-endian mode to 
big-endian mode by running the "rum psr.be" instruction. But that would 
obviously be crazy and I don't know anyone who would do that :-)

> > >Running 32bit and 64bit envs side-by-side on a single processors is a
> > >use-case we need to keep in mind. But running LE and BE processes
> > >side-by-side on the same CPU? I am pretty sure that loonies who'd do
> > >such a thing will run into a lot of other problems before they run
> > >into this particular issue with D-Bus. And then, if it matters to them
> > >they can send us a patch!
> >
> > They'd probably run into other problems, but nothing major I think. They
> > have to compile the entire library stack in big-endian mode, but that's
> > it.
>
> Sure, they can recompile dbus then, too.

They could, but they don't have to. They can have two libdbus-1 installed: one 
for big-endian and one for little-endian mode. Besides, there are other 
implementations out there that don't use libdbus-1.

If I'm not mistaken, Java is endian-neutral and the Java binding will then 
generate only one endianness format.

> The problem is not generally LE vs. BE. The problem is whether we care
> about folks who want to run LE and BE processes at the same time and
> communicate via D-Bus.

We do. That's why the byte order mark is in the protocol in the first place. 
Though, of course, it's also required for networking.

> > In any case, when you receive the file descriptors via SCM_RIGHTS, are
> > they in original byte-order or are they in the native (receiving)? Is
> > there anything to byte-swap?
>
> It's a local transport. They are always in native byte order.

My point is that the actual file descriptors are received in a special Unix 
recvmsg. Is that already native byte-order, regardless of the encoding of the 
D-Bus message?

If that's what you meant, then there's no need for byte swapping. There's also 
no need for an assertion.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Software
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090505/ed656ca6/attachment.pgp