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?
Attachment:
signature.asc
Description: This is a digitally signed message part