[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] blktap, qdisk, xl cd-eject, and xencommons

On 30/04/13 13:38, Jan Beulich wrote:
On 30.04.13 at 14:16, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
On 04/30/2013 12:54 PM, Wei Liu wrote:
On Tue, Apr 30, 2013 at 11:56:35AM +0100, George Dunlap wrote:
Well we didn't have that before 4.3, and it didn't seem to be a major
                                    4.2 maybe?
problem; I think people just knew to make sure blktap got modprobed
themselves.  So I wouldn't personally consider this a blocker -- but I'm
still open to other ideas.

In any case, it would certainly be *better* if we can have libxl attempt
a modprobe, so if we can get it in before the release, I think that
would be a good thing.

So now the libxl infrastructure is no longer a blocker, good. Then how
can we justify it if we need it to go in at this stage? We're
approaching RC1 next week, what is the suitable policy for this
Well most of those things are "guidelines" rather than rules. :-)  Not
everything fits neatly into the packages.  In this case, this is a mild
regression from 4.2 -- so it could be sort of considered a "bug fix".

OTOH, if Jan were willing, the lowest disturbance thing to do might be
to leave the modprobe in, and promise to address the issue first thing
in the 4.4.  (In that case I'd owe Jan a big apology, as it was I that
promised to sort it out for 4.3.)
If this turns too intrusive at this point I wouldn't heavily object,
but would raise the question of what if the same happens during
the 4.4 cycle again.

So our options, AFAICT, are as follows:

1. Remove modprobe from xencommons, try to put a modprobe into libxl.

This introduces new, potentially risky behavior at the 11th hour.

2. Remove modprobe from xencommons,

This introduces a mild regression: people who are using blktap now have to make sure that blktap gets loaded.

3. Punt for 4.4.

#2 isn't terrible, I don't think, but overall I think #3 is the best option for users, although it means me having to say I'm sorry for failing to follow through on a commitment. :-)

To answer your question about the 4.4 cycle:
1. We have a much clearer idea about what needs to be done now
2. I have a much clearer idea about how long a fix might take, so I will work on it first thing in the cycle.

So unless you (or someone else) objects, I think I'm going to move the xencommons thing to a "for 4.4"


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.