This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] add a way to disable xen's udev script.

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] add a way to disable xen's udev script.
From: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Date: Thu, 9 Jun 2011 10:01:40 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 09 Jun 2011 02:06:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1307605345.775.758.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4DEFA993.1020803@xxxxxxxxxxxxx> <1307554945.4176.47.camel@xxxxxxxxxxxxxxxxxxxx> <4DEFCC40.3000103@xxxxxxxxxxxxx> <1307562567.4176.57.camel@xxxxxxxxxxxxxxxxxxxx> <4DEFDCB5.4020301@xxxxxxxxxxxxx> <1307605345.775.758.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100821 Icedove/3.1.2
On 06/09/2011 08:42 AM, Ian Campbell wrote:
and of course working with the maintainer of the package you wish to
integrate with is clearly out of the question?

This is an upstream issue in the first place. The assumption that everyone is supposed to use those *globally* installed udev scripts that are targeted to xend and to some extent xl, is simply false.

While i used the debian package as an example, the same is true for every other xen packages that i looked at.

And adding a Conflicts entry is just not a solution either, since you need install/removes packages (and restarting udev) to switch toolstacks whereas my solution involves no such thing.

In any case, installing multiple toolstacks in parallel would *have* to
have a *dynamic* way to execute different udev scripts, which I might argue that's exactly what i provide in a very simple way with a dummy file mechanism (not ideal mechanism, but just does the job trivially).

There's more than likely a perfect way to splice the packages to make it
a package issue only, however I'm not terribly interested in putting
more efforts than a *trivial* 1 line change.

Sorry, but I don't think you motivation or lack thereof justifies adding
this sort of hack to the upstream Xen code base.

Please. joking so early !
Those scripts are hacks in the first place, and are taking advantages of udev flexibility to do horrid stuff.


Xen-devel mailing list