Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about launchd

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:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden

This email sent to email@hidden
References: 
 >Questions about launchd (From: Michal Taurich <email@hidden>)
 >Re: Questions about launchd (From: Dave Zarzycki <email@hidden>)
 >Re: Questions about launchd (From: Terry Lambert <email@hidden>)
 >Re: Questions about launchd (From: "Finlay Dobbie" <email@hidden>)
 >Re: Questions about launchd (From: Terry Lambert <email@hidden>)
 >Re: Questions about launchd (From: "Finlay Dobbie" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.