Re: Questions about launchd
Re: Questions about launchd
- Subject: Re: Questions about launchd
- From: Terry Lambert <email@hidden>
- Date: Sat, 25 Aug 2007 06:05:39 -0700
On Aug 25, 2007, at 4:40 AM, Finlay Dobbie wrote:
On 25/08/07, Terry Lambert <email@hidden> wrote:
Certain command conform to standards, and for those commands, we more
or less say we expect that they will continue to conform to
standards.
Which commands? What standards?
I'm aware that you're playing devil's advocate here, but I'll give you
a straight answer anyway...
UNIX Commands. ISO/IEC/POSIX/ANSI and other standards, the list of
which may change over time, as deemed appropriate.
We define our API at the top of libc, not at the user/kernel
boundary. Internally, as an implementation detail, at the user/kernel
boundary we occasionally use data interfaces rather than procedural
interface. In technical terms, this is "a pig trick", and we can get
away with it because the places we use it are very, very constrained,
both by locality and by temporal relationship to us shipping new
kernels. Some of these are in libraries, and some are strictly in
applications, with no way to share the code, other than at a source
level.
For example, I shudder when anyone tries to write/use their own C
libraries not derived from Apple sources, because I know that there
are a number of real system calls at the user/kernel boundary that
take more parameters than the ones exported by the library, and use
symbol decoration in order to select between binary backward
compatible interface implementations. The library actually has two
(or more) implementations, and which one you get depends on who's
asking for it. One of them passes one value in for that extra
parameter, while the other passes a different value. I seriously
doubt whether a third party could make this work reliably without
using our sources as a basis for theirs.
Most data interfaces implemented this way are unsupported, meaning you
should be prepared for your code to break on each and every software
update. Programs like "lsof" and "ps" and "netstat" and so on use
these interfaces, and that's OK: we're prepared to change them every
time we change a data interface, and they ship with the OS, and if the
OS is revised in such a way that they would break, then the command is
also revised, so that they don't break, and it ships the same time the
OS does to everyone who gets the new revision of the OS, and never to
people who do NOT get the new revision of the OS.
Unless you also ship with every SU, or are willing to update your
customers each time an SU ships AND have some magic way of detecting
when this happens, without warning beforehand that something will
break, OR are willing to tolerate something not working for a customer
until you can get a fix out... you are discouraged from using these
interfaces directly. The same way that if you are a KEXT author, you
are discouraged from declaring a dependency on kernel functions not
listed in one of the supported KPIs (for the same reason: if an
internal kernel implementation detail changed, your KEXT would break).
Clearly the best solution is a supported API ;o)
Actually, no. The best solution is to not need to recreate
information you had, and then "forgot" to save off for later use, and
then "needing" to use it later.
For example, people who have programs that rendezvous via have one
program find the process ID of the other programs via "ps" (or
"sysctlbyname") should instead have the program they want the
rendezvous with record it's pid in a file named after the process in /
var/run. That's the proper convention, and it saves the people who
use it a whole lot of pain ("configd", for one, uses this convention).
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden