All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Russell Coker <russell@coker.com.au>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: 3.16.0 Debian kernel hang
Date: Fri, 4 Dec 2015 11:13:19 -0500	[thread overview]
Message-ID: <5661BB9F.3010908@gmail.com> (raw)
In-Reply-To: <201512050126.09510.russell@coker.com.au>

[-- Attachment #1: Type: text/plain, Size: 2789 bytes --]

On 2015-12-04 09:26, Russell Coker wrote:
> On Sat, 5 Dec 2015 12:53:07 AM Austin S Hemmelgarn wrote:
>>> The only reason I'm not running Unstable kernels on my Debian systems is
>>> because I run some Xen servers and upgrading Xen is problemmatic.  Linode
>>> is moving from Xen to KVM so I guess I should consider doing the
>>> same.  If I migrate my Xen servers to KVM I can use newer kernels with
>>> less risk.
>>
>> That's interesting, that must be something with how they do kernel
>> development in Debian, because I've never had any issues upgrading
>> either Xen or Linux on any of the systems I've run Xen on, and I
>> directly track mainline (with a small number of patches) for Linux, and
>> stay relatively close to mainline with Xen (Gentoo doesn't have all that
>> many patches on top of the regular release for Xen, aside from XSA
>> patches).
>
> I don't think that Debian does anything wrong in this regard.  It's just that
> my experience of Xen is that it is fragile at the best of times.  The fact
> that Red Hat packaged the Xen kernel in the Linux kernel package is a major
> indication of Xen problems IMHO, the concept of Xen is that it shouldn't be
> tied to a Linux kernel.
In the case of Red Hat, that's probably the way it's done because that's 
originally what was needed to make things work.  Early versions of Xen 
very much did need a special version of Linux running as Domain 0. 
Coupling things like that also simplifies testing for the developers at 
Red hat, as they then only need to test one combination, instead of a 
big matrix of features.  Less to test means they can test more 
thoroughly, which means they can provide a better guarantee that things 
will work without intervention right out of the box, which is important 
for enterprise distros.

Xen is supposed to be decoupled from the version of the Domain 0 kernel, 
and in most of my experience with it, they do a pretty good job.  90% of 
the issues I've heard of personally have been with patched versions put 
together by Linux distros, not with an upstream release.
>
> If you haven't had Xen issues then I think you have been lucky.
>
I have personally had issues using Debian as Domain 0 and keeping Xen up 
to date myself, but all of those issues vanished when I switched to 
Gentoo for that purpose (well, they vanished when I switched to NetBSD, 
but haven't resurfaced since I switched from that to Gentoo Linux after 
about a week of pulling my hair out from fighting with BSD). I'm 
admittedly not doing anything other than small purpose built PV domains 
for service isolation in most cases (although I do use a dedicated PV 
domain for testing kernel patches from time to time), but that really 
shouldn't have any impact.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-12-04 16:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04 10:00 3.16.0 Debian kernel hang Russell Coker
2015-12-04 13:08 ` Austin S Hemmelgarn
2015-12-04 13:42   ` Russell Coker
2015-12-04 13:53     ` Austin S Hemmelgarn
2015-12-04 14:26       ` Russell Coker
2015-12-04 16:13         ` Austin S Hemmelgarn [this message]
2015-12-05 12:44   ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5661BB9F.3010908@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=russell@coker.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.