Mailinglist Archive: opensuse-kernel (131 mails)

< Previous Next >
[opensuse-kernel] Re: cgroup support in kernel
  • From: "Brian K. White" <brian@xxxxxxxxx>
  • Date: Thu, 18 Feb 2010 02:06:43 -0500
  • Message-id: <4B7CE703.5060107@xxxxxxxxx>
Michal Marek wrote:
On 16.2.2010 21:44, Brian K. White wrote:
Hi,

Hi Brian,

please use the opensuse-kernel mailing list (an pick a better subject
next time...). I also added Jiri, who maintains the lxc package in Factory.

Ah sorry the web link on the OBS page autofilled that and I never even looked at it.


cgroup support is missing from the desktop kernel. Is this intentional
or accidental?

Intentional, see https://features.opensuse.org/305694 and
http://gitorious.org/opensuse/kernel-source/commit/c065c52q1 .

OK I see now. So it's performance overhead and it's uncommon utility make it one of the things it makes sense to remove from a desktop-tuned kernel. Ok no problem.

Then the question becomes, why, when I choose the "minimal text-only system" during install, and make no other software choices, do I get the desktop kernel instead of the server one? If that target isn't a "server" target, what is?


It breaks LXC which requires it. All other LXC options are enabled in
the desktop kernel but the one can't work without the other so you might
as well turn the other lxc options off also, or turn cgroup on.

BTW, which are these options?

Got me there. I knew there were several options that needed to be enabled and I knew they all were, but I hadn't actually gone over them. I see now none of them look lxc-specific. Sorry for _that_ noise.


The problem with userspace packages depending on certain kernel features
or versions is that it doesn't really do what you want. You can express
a dependency on an installed package, but what really matters is the
running kernel, which rpm can't test for. Also if you depend on a
certain kernel flavor (or some virtual capability provided by some
flavors), the effect would be that the installer would install the
desired kernel flavor _alongside_ with the "wrong" flavor, because
different kernel flavors don't conflict with each other. Just something
to keep in mind.

hmm? I thought all along you could depend on say, a file, say, /bin/ksh, and it doesn't matter how that file got there, rpm is satisfied. And if it's not there, then one of the several possible packages that each supply that file (bash supplies a symlink which is a lie and that I hate that it does that..., and pdksh, and of course ksh93 (zsh too but I don't know offhand if opensuse's rpm of it does) all also can supply their own version of the same file. When it's missing and a package depends on it, ... I don't know what happens. I'll go mock up a test now and answer my own question.

Maybe what I can do is have the lxc package do a test at install-time in %prein, toss up a message telling the user what to do, and then abort/fail the install?

That way it isn't simply installable broken, nor do I force a bad requirement of any specific kernel to the exclusion of any other.

--
bkw
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx

< Previous Next >
References