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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 04/30/2013 11:22 AM, Wei Liu wrote:
> On Tue, Apr 30, 2013 at 11:02:38AM +0100, George Dunlap wrote:
> [...]
> > The second is problems with xl cd-insert and eject, initially reported
> > by Fabio Fantoni, and then (accidentally) reproduced by me.  The problem
> > turns out to be libxl using blktap for cdroms.  Basically, AFAICT, the
> > whole cd-insert cd-eject thing completely doen't work if blktap is used
> > to provide it; and it's not a simple fix.
> >
> > To address these issue for 4.3, I would like to propose:
> >
> > 1. Have libxl default to qdev for everything, except for things that it
> > needs blktap for (like vhd, IIRC)
> >
> > 2. Simply remove the hard-coded modprobe from xencommons
> Presumably you only mean "modprobe blktap ..."?
>
> > 3. Add code into libxl to do modprobe-ing as part of the "does this
> > system support blktap" check.
> >
> > But I think #3 can probably wait until 4.4.
> I don't quite understand 2, 3 and the statment "#3 can probably wait
> until 4.4". If blktap is necessary for VHD, we can not simply remove the
> modprobe while not adding infrastructure in libxl to automatically load
> blktap.
Well we didn't have that before 4.3, and it didn't seem to be a major 
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.
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel