Re: upstart: please update to latest upstream version
On Sat, Feb 25, 2012 at 12:17:43AM +0200, Uoti Urpala wrote:
> Roger Leigh wrote:
> > On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote:
> > > > [note: it's somewhat desirable for them to be optional on Linux
> > > > too, to prevent feature lock-in and future compatibility problems].
> > >
> > > Unix kernel development outside Linux is pretty limited, especially
> > > development for features other than server use. I think "avoid requiring
> > > Linux-specific features" would turn into "avoid technology developed
> > > after the 90s".
> >
> > This is missing the point. I'm not saying "don't use Linux-specific
> > features", I'm saying that use of Linux-specific features should be
> > /optional/, even on Linux. Only use them if present.
> > Let's take cgroups as an example. They are an optional feature
> > even on Linux.
>
> As are several fundamental POSIX features.
POSIX features, optional or not, are standard and will not change
incompatibly. If not present, one would expect an ENOSYS error return
and the code should cope with that eventuality.
cgroups is both non-standard, changing rapidly, and does not have a
guaranteed future. It's somewhat controversial even amongst kernel
hackers. Relying on it is, to put it mildly, short-sighted.
> > Portability to other systems is really just a special
> > case of portability to future versions of the Linux kernel. Things
> > can and will change, and systemd needs to make sure it doesn't
> > break horribly when it happens.
>
> What's your problem scenario here? That kernel upstream suddenly decides
> it's OK to completely break systemd? I don't think it's that much more
> likely than them deciding to break POSIX functionality. If they want to
> tweak the APIs, then that can be coordinated with systemd without
> causing any catastrophic breakage. Even without Debian, the install base
> for systemd is already large enough to ensure that the kernel can't just
> ignore backwards compatibility.
Excuse me, but what you're implying here is that systemd can dictate
the development of kernel interfaces. Sorry, but that's too far.
Can't you see the massive problem here? You are now preventing
cgroups being removed from the kernel, and this has big implications
for kernel development going forward. It's not exactly loved even
now, and you're lumbering us with it indefinitely... Not a sensible
attitude.
We've already seen the effects of the close relationship between the
kernel and udev. It has caused upgrade issues in the past, but at
least at the moment has been manageable. Tight-coupling between
components is almost always a bad idea. This has the potential to
cause horrible issues during upgrades, when compatibility issues
between systemd and kernel versions make upgrades either impossible,
or cause massive breakage. One situation we never want to see is a
system rendered unbootable as a result of a kernel/systemd
incompatibility. By only using cgroups *if available at runtime*, you
avoid the issue entirely by having a fallback *if not present*.
Again, cgroups is just a single example, and the above applies equally
to all Linux-specific non-standard interfaces.
Enabling systemd to run on non-Linux architectures has the massive
benefit of ensuring that it will also run on all Linux kernels as
well. Using advanced features is fine, and appreciated. Mandating
their use or failing to work in their absence is not. We do not
want to require the kernel and systemd to be upgraded in lockstep.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: