On Thu, 2009-07-23 at 15:23 +0200, Michael Biebl wrote: > Adding Scott to CC as he's not subscribed, too. > Thanks. First, my general thoughts on porting: When writing Upstart, I've only focussed on Linux. To make writing it as easy as possible, and provide the features I want with the minimum of fuss, I've used APIs that are Linux-specific. This goes for both kernel APIs, including assumptions about the behaviour of a kernel API that may not be quite portable; and to assuming glibc and gcc. Off the top of my head, Linux-specific thing that the current and next versions use/will use are: - inotify - waitid() - epoll, eventfd, signalfd, timerfd - ptrace - netlink proc connector - netlink udev interface There's probably a bunch of other Linux-specific things I've used without even being aware of it (in that I didn't have to read kernel documentation or source to figure it out <g>). I don't think that this is a bad approach; Upstart's target has always been the Linux distributions, it was never expected that other traditional UNIX implementations would adopt it -- the two remaining have their own alternatives already, and practically impossible to envision a Windows port ;-) Where it does come up though is those Linux distributions that have the option of using alternate kernels. In these cases, what I think we really want to see is a version of Upstart as equally bound to the FreeBSD kernel as Upstart currently is to Linux. To do this properly, I think it needs FreeBSD programmers to branch off the current Upstart code and rewrite such portions as are necessary to fully support its features on FreeBSD. This includes features such as filesystem watching, process following, etc. using the optimum code path on the BSD kernel as it can. (From what I know of the BSD and Solaris kernels, this may even be easier than on Linux since we've had to invent things in Linux). I'm not really happy with the idea of just disabling features; if there's going to be a FreeBSD port it should be just as featured as the main Linux version - even if that means doing development work on FreeBSD to support it. The port would live in a separate branch (upstart-freebsd I would guess), and merge code from mainline when necessary. Along the way we'll figure out what code changes are necessary to the mainline to make that merging easier, isolating kernel-specific parts away from generic parts where it makes sense. (I suspect the code is already largely along these lines anyway). The one thing I'm _not_ keen on is #ifdef. I think it makes code significantly harder to read and understand, and especially to fix bugs - since you have multiple code paths to change. I'm also against having multiple backend "modules" in the same source tree for much the same reason. I think the best way to deal with ports is to use revision control, and separate branches. For example, it becomes trivial to see what changes (e.g. bug fixes) to mainline have not yet been integrated into the FreeBSD port: bzr checkout lp:upstart/freebsd upstart cd upstart bzr missing lp:upstart Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Description: This is a digitally signed message part