One could argue about the knock one effects, i.e. that other
programs should
not be parsing DISPLAY outwith of the X trans library, but they
are. So now
there are patches for ssh to handle the new DISPLAY format, and
similarly
patches to xauth.
I can and will, and you correctly summarized my argument. :)
I _think_ it could all have been hidden within the trans library
without any
need for a new type/name of socket, and so no externally visible
change.
At worst it would have been specialised code in the Xserver, and
something wrt
launchd (i.e. does one just hardcode the "/tmp/.X11-unix/:%d"
pattern in
to it, or try to use some form of helper / decoupling?).
It would have required a source change to launchd, to teach it how X11
socket naming works and how it should pick one given existing user-
created sockets. Launchd is a critical operating system component in
Mac OS X. I'd rather change some code in Xtrans to add flexibility in
the way unix socket pathnames are constructed than add code to launchd
to work around inflexibility in X11.
I'd certainly be willing to hack up how I think it should be done,
but then
I'm still on tiger. (I need to get the server compiling anyway), I
_believe_
the launchd source is public?
It is, under the Apache license. Warning: I know that LaunchAgent
(per-user context jobs, as opposed to LaunchDaemon per-system context
jobs) support is missing or broken in the version of launchd shipped
with Tiger. I have no idea whether or not it's possible to run the
latest launchd on Tiger, although it would be great if that were the
case.
However I was assuming that the xinit race was a consequence of the
changes to
handle passing the socket, and that it was because the per client
socket was
accepted in launchd and passed, then recorded early in the trans
related code,
rather than allow the trans code to simply do its own thing based on
passing
the listening socket fd. (This is pure speculation on my behalf).
Okay, then I'll admit that I didn't go bother to check to make sure
what I said was right, so I may be mistaken. Sorry. :)
I've already mentioned this is possible. And can you identify a
program that is
actually relying on the assumption that the socket is there?
Off the top of my head no. But code is relying upon being able to
parse DISPLAY.
And it's bad. Bad code! Tsk tsk!
Seriously, there are a lot of weird DISPLAY naming schemes that this
other code may or may not properly handle. For example, you can
specify "unix:0" to explicitly tell it to use a Unix socket, or "tcp:
0" to tell it to use port 6000, or you could use a DECnet address and
have two colons in the address. Apparently the screen name could once
have a slash followed by a "catalogue list", which according to the
Xtrans source is "currently unused".
Also, the assumption that that ':0' means a socket with the pathname
of "/tmp/.X11-unix/X0" is not safe on all platforms; specifically,
HPUX seems to put sockets in /usr/spool/sockets/X11/.
What is _gained_ my using an alternate socket, that could not have
been achieved
without it. Similarly what is _gained_ by defining a new
interpretation for DISPLAY,
that could not have been hidden in the x11 transport library?
... but it was hidden in the X11 transport library (libX11).
--
Ben Byer
CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/x11-users/email@hidden
