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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120228165118.gq24...@codelibre.net