WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

On Thu, 2011-06-09 at 10:01 +0100, Vincent Hanquez wrote:
> 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.

Right, because the packagers haven't realised that there are toolstacks
which don't use these same hotplug scripts, because up until now there
has been no effort to package xapi outside of XCP.

Instead of working around that why aren't you working to fix the
situation in the packaging (even by simply reporting bugs)?

If there are things we can do in the upstream build to help with this
then lets do them. For example adding CONFIG_XEND and CONFIG_XL and
installing the hotplug script iff one is enabled.

> 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.

Sure, a conflicts is also not really solving the issue properly. But it
is solving it more properly (or at least more upfrontly) than yours.

> 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).

And I pointed you towards a good proposal for making this dynamic
decision, which is not a hack, and which has utility over and above the
case of just disabling the udev scripts.

> >> 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.

Feel free to suggest patches which implement any better scheme you have.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel