relaunchd: a portable clone of launchd

[Hubbard Jordan]

> I personally use those terms a bit tongue in check. BSDs have very limited manpower , and so they are forced to use source code from foreign OSes in the most straightforward way possible, which means wrappers . (else see the fiasco with the DRM drivers in FreeBSD so far, there is plainly too much effort to port Linux DRM code to BSD without wrappers and adapters. Dragonfly did it the right way  ) . So , you need to wrappers and adapters to Linux  specific API’s and data structures  to support DRM , OFED and god knows what else. 

I don’t disagree with the “limited manpower” statement (it’s manifestly obvious), but perhaps a less negative way of looking at this is to say that since OSes have become largely commoditized (a natural consequence of changing educational trends in computer science), we’re better off not reinventing any wheels and simply adopting whatever off-the-shelf technologies and solutions allow the mission goals to be achieved in the shortest period of time.

> But this is a general problem not only limited to Linux. 

Indeed.  There’s also arguably a sweet spot between “emulate all the things” (and convince some segment of your own fan base that you’re dying because nobody uses the “native offerings”) and “emulate the most strategic things” vs spending so much time re-inventing wheels for the sake of it that you miss the window of relevance entirely.

> FreeBSD has NDIS emulation to support some Wifi devices. 

Yes, the infamous “Project Evil”. :)  I don’t know how much that has actually been used in production scenario, but it was an interesting project.

> FreeBSD has Solaris API/ datastruct  wrappers and adapters to support ZFS/

Which has been a pretty huge success, really.  ZFS is very stable on FreeBSD (comparatively speaking to ZFS on Linux) and has opened some entirely new markets for it.  Had FreeBSD insisted on “doing it natively” it’s pretty arguable that OpenZFS would have gone its own way and ZFS would be an unstable science experiment that nobody would trust their bits to.  Sure, there is still some weirdness with ARC behavior and the memory consumption of features like Dedup (which is more OpenZFS’s fault than FreeBSD’s) but the shims work well and make it possible for the same code base to build on Illumos, which is still the reference code base, and FreeBSD.  I’d say this has been a Big Win.

DTrace has also been a similar win, and is more “foreign DNA” in FreeBSD.  You’d like to see more of Solaris’ SMF in FreeBSD, and I agree.  I wouldn’t mind Solaris Doors, either.  It would have made NDMP support far more of a drop-in than it has been so far.   I think we’re in violent agreement so far on the subject of Solaris DNA!

> NextBSD has now dragged  “half" of mach kernel inside to : 1. Implement a better and more flexible IPC mechanism than Unix domain sockets / posix message queues (Truth is, IPC sucks in Linux and BSDs. It is my opinion that Windows LPC/ALPC are way better designed. and 2: To easily port launchd/notifyd/whateverd

That’s mostly all true, though I think Mach IPC’s feature set deserves just a wee bit more respect than it traditionally gets (or is fully described above).  

The fact is, IPC on Unix has traditionally sucked and nobody has yet to provide an alternative to Mach IPC which ticks all the same boxes.  A hierarchical namespace that can be used to create privilege domains (providing a very key ability to control who can talk to who) - Check.  Supports service discovery as an intrinsic property without the presence of a filesystem (e.g. pre-mountroot) - Check.   Provides audit trailers in every message that make it possible to validate who you’re talking to and create “trusted delegates” for certain services that would otherwise be forced to be in the kernel - Check.  The ability to pass shared memory descriptors out-of-band for large messages - Check.  That’s not even a full list, but it covers some features that OS X and iOS use in many different ways to good effect.

Believe me, if there was something better, with the right high-level semantics (which alternatives like L4 IPC do not provide) combined with low-level capabilities like allowing the kernel to talk to userspace using the very same IPC mechanisms, we’d use it.  Since there isn’t, we stick things like XPC (which NextBSD is doing a clean-room implementation of) on top of Mach IPC to avoid the horror of using MIG and doing RPC programming from the 1980s, and we spend the time we’d otherwise have to spend creating an entirely new and unproven IPC mechanism (which might very well fail to impress anyone after we finished) and focus instead on creating the services that use it.  Seems like a reasonable example of “code re-use” to me!

> Now this is all good and dandy, but who will audit all this code for bugs and security ? Some bugs will become manifest fast, but others may lurk in those layers for years.

I agree, which is actually all the more reason to adopt existing code.  It’s been vetted.  It’s been tested.  It’s been used for many years across many different releases of software on literally millions of devices.  Seriously, how much better than that can anyone reasonably expect or hope for?  If there’s a way to set the bar even higher for auditing / proving the efficacy of a body of code, I’d be more than willing to learn about what that is.  You can probably imagine that a lot of people, both paid and unpaid, have attacked the hell out of every byte of code in iOS and OS X.  The jailbreaking community alone has certainly had the incentive, and with incentive comes inventiveness.

> — problem : binary code reuse ---
> 1. Many utilites from BSD base are monolithic and closed, yet they provide higher level interfaces to OS configuration. It is my opinion that 
> all this functionality should be expose as libraries & demon services.

Violent agreement, for the most part.  I don’t know how we’d define “all the functionality” of course, and the idea of wrapping everything from df(1) to yacc(1) would obviously cause someone to question the sanity of any person proposing such a blanket approach to the utilities in question, but you’d hardly be the first person to suggest wrapping or re-writing all of the more useful building-block commands in terms of libraries and services.  Taking an aggressively SOA-oriented approach is obviously what has allowed companies like Amazon to encompass the almost unbelievable amount of territory they now do without collapsing under their own weight, so if anyone needs an existence proof, there it is (along with countless others).

> This is the very base upon which enterprise grade tools  are built. Libxo is not a proper solution to this problem. It should not exist in FreeBSD base, yet somehow it slipped inside, and I seen on some papers from BSD conferences that some even discussed to put it inside the OS kernel . I frankly cant imagine what those ppl are/wehre thinking. 

Oh, I dunno, I think you’re being a little harsh.  I’ve looked at libxo and I think it’s reasonable enough as a generic text output library.  But that’s all it is.  It’s not a policy, it’s certainly nothing like what we’re describing above, it’s just a building block.  Perhaps the bigger criticisms should be reserved for what it’s not, instead:

1. It’s not a plan to actually take a set of commands like find, xargs, du, ls and so on and impose some structure on them.  It’s certainly not a proposal which even attempts to identify “the right commands” and postulate a set of use case scenarios that will allow the user to create some truly interesting shell scripts which use these new structured input/output capabilities to do things not formerly possible.

I speak from a little experience here as we did that science experiment back around 2007 or so, just to see what it might look like to create a subset of Unix command which all spoke XML natively, and the results were surprisingly elegant when able to decouple “mechanism” from “presentation” (a command which simply stats a file and presents the information from it as an XML blob doesn’t have to worry about multi-column output or human readability concerns - that’s for another tool further down the pipeline to do).  I kind of have no interest in this topic, however, because it just sets off the “you can have my 80 column, ISO-Latin1 text commands when you pry them (and my VT100 terminal emulator) from my cold, dead fingers!!” crowd. :-)

2. It doesn’t provide one of the APIs MOST lacking from *BSD right now, which is how to set and get structured preference information for a utility of any complexity.  Yeah, I’m talking about the equivalent of CFPreferences here (and the services equivalent of cfprefsd) - since everyone already expects me to quote Apple APIs, why disappoint them? :)   The biggest consumers of structured data are actually services trying desperately to find a KVS somewhere, not people writing shell scripts.  Oh yeah, you touch on that later.  More in a second.

> — problem OS configuration and updating in a higly concurrent world ---
> 3. Transactional OS wide configuration databases. 

Which, of course, we use every day with FreeNAS.  When you’re an appliance, you’re not allowed to look through half of /etc (or export half of /etc as part of a “save configuration” operation) and yeah, we do it through a database abstraction layer that lets anything from postgres to mongodb provide the actual storage.  I suppose it’s arguable whether the “configuration database library + service” actually needs to live in base, but there are so many utilities that will continue to roll their own otherwise, it seems silly not to.

> 4. In a world where hundreds of machines, bee-it physical or virtual are interconnected and talking to each other , safe concurrent access to OS configuration will become soon very important.

This is already the case.  Most chef / puppet / vagrant setups bend over backwards to try and impose order on what are otherwise rather uncooperative OS instances deployed in the hundreds or thousands.

> 4. A new high performance IPC system should be introduced IMO. It should allow both fast synchronous operation ( like solaris doors) and asynchronous operations, working with kevent/kqueue. It should allow kernel endpoints, and should cater to security concerns. It should be a minimal API , not a full buss

Right.  Mach IPC. :-)

> 5. a user mode pub / sub message bus.  use the IPC api to implement a high performance , OS wide, message bus. It should present clear abstractions to clients, to insulate them from using syscalls directly. It should sum some already existing mechanisms, such as devd.

XPC + system notifications do a pretty good job of this.  It depends on what you’re “subscribing” to.  A distributed notification?  Some peer-to-peer communication from another system service?  A configuration knob that can change dynamically?  It’s tempting to try and fold them into a single pub/sub namespace, but it’s not clear to me that this is a good thing or not, or if it’s simple better to allow each of the above services to provide a nice call-back mechanism that works with a universal glue library (like, *cough cough* XPC and/or libdispatch).

> — problem of service management and fault management:
> 
> 6. Much needed components of enterprise. 

Do you know how much of Solaris SMF escaped into Illumos before Oracle slammed the door there?  I’ve honestly never looked.

> I raise some of those problems in past. Especially the problem of binary code reuse . My perception was that nobody really gives a damn.

I think the problem with the FreeBSD community in general is that there ARE people who give a damn, but they are essentially blocked into ineffectiveness by another caucus who doesn’t want any of these things to change.  It’s like the Senate - you have Republicans and Democrats who see eye-to-eye on almost nothing and their principle power is in being able to block whatever initiatives “the other side” proposes and, well, Democracy Inaction. :-)

>  Others complained that people talk and nobody contributes code , yet when you contribute code they dont look at it with months, and so on.

Hence us trying to just prove the “working code” requirement first in NextBSD and if nobody looks, well, that’s OK too - we can still use it for our own purposes.  Maybe some other Appliance vendors will jump into the mix and use it for their purposes too.  We have more progress to make before I’d even try to “sell” it for any purpose whatsoever yet, however.  One step at a time.

> Yes. See, One thing I hear for decades is the Unix desktop.

Which I still think will probably never succeed for as long as the X Window System is in the mix because its APIs, and the mechanisms it forces into place, are just a horror show, even with all the KDE / Gnome libraries and services that folks tried to add on top to paper over the differences.  You can’t polish a turd, you can only paint it. :-)   And yeah, I wrote Window Managers (like awm) and widget libraries and such Back In The Day for X.  I was a believer.  Then I tried to port Lotus 1-2-3 to it. :(

- Jordan