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

Add a way to disable xen''s udev scripts by using a dummy file.

Signed-off-by: Vincent Hanquez <vincent.hanquez@eu.citrix.com>

diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh
b/tools/hotplug/Linux/xen-hotplug-common.sh
index 370f9ad..e248cae 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh
@@ -22,6 +22,8 @@ dir=$(dirname "$0")
  . "$dir/xen-script-common.sh"
  . "$dir/locking.sh"

+[ -f "$dir/NOEXE" ] && exit 0
+
  exec 2>>/var/log/xen/xen-hotplug.log

  export
PATH="${BINDIR}:${SBINDIR}:${LIBEXEC}:${PRIVATE_BINDIR}:/sbin:/bin:/usr/bin:/usr/sbin:$PATH"

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

On Wed, 2011-06-08 at 17:55 +0100, Vincent Hanquez
wrote:
> Add a way to disable xen''s udev scripts by using a dummy file.
Why?

Does one of "chmod -x" or "rm" not suffice?
> 
> Signed-off-by: Vincent Hanquez <vincent.hanquez@eu.citrix.com>
> 
> diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh
b/tools/hotplug/Linux/xen-hotplug-common.sh
> index 370f9ad..e248cae 100644
> --- a/tools/hotplug/Linux/xen-hotplug-common.sh
> +++ b/tools/hotplug/Linux/xen-hotplug-common.sh
> @@ -22,6 +22,8 @@ dir=$(dirname "$0")
>   . "$dir/xen-script-common.sh"
>   . "$dir/locking.sh"
> 
> +[ -f "$dir/NOEXE" ] && exit 0
> +
>   exec 2>>/var/log/xen/xen-hotplug.log
> 
>   export
PATH="${BINDIR}:${SBINDIR}:${LIBEXEC}:${PRIVATE_BINDIR}:/sbin:/bin:/usr/bin:/usr/sbin:$PATH"
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

On 06/08/2011 06:42 PM, Ian Campbell wrote:
> On Wed, 2011-06-08 at 17:55 +0100, Vincent Hanquez wrote:
>> Add a way to disable xen''s udev scripts by using a dummy file.
>
> Why?
>
> Does one of "chmod -x" or "rm" not suffice?
Because it provides the ability to install side-by-side multiple 
toolstacks, including one that doesn''t use the xen''s xend udev
scripts.

chmod -x and rm would do the same things (provided udev isn''t unhappy),
but modifying files of package A from another package B is highly 
frowned upon.

-- 
Vincent

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

On Wed, 2011-06-08 at 20:23 +0100, Vincent Hanquez
wrote:
> On 06/08/2011 06:42 PM, Ian Campbell wrote:
> > On Wed, 2011-06-08 at 17:55 +0100, Vincent Hanquez wrote:
> >> Add a way to disable xen''s udev scripts by using a dummy
file.
> >
> > Why?
> >
> > Does one of "chmod -x" or "rm" not suffice?
> 
> Because it provides the ability to install side-by-side multiple 
> toolstacks, including one that doesn''t use the xen''s xend
udev scripts.
> chmod -x and rm would do the same things (provided udev isn''t
unhappy),
> but modifying files of package A from another package B is highly 
> frowned upon.
Dropping down a file which unilaterally disables critical behaviour in
another package requires isn''t really much better, you might as well
just add a Conflicts: and be done with it.

In
http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2011-April/003362.html
the Debian package maintainer proposed a scheme by which xm and xl could
coexist. Adding "xapi" (or whichever other toolstack you are
considering) as an option to that scheme and having all the sets of hotplug
scripts check that their scheme is active seems like a reasonable solution to
me.

Of course in the longer term we should attempt to converge the hotplug
scripts of the different toolstacks into a single set of (e.g. libxl
based) scripts.

Ian.


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

On 06/08/2011 08:49 PM, Ian Campbell wrote:
>> chmod -x and rm would do the same things (provided udev isn''t
unhappy),
>> but modifying files of package A from another package B is highly
>> frowned upon.
>
> Dropping down a file which unilaterally disables critical behaviour in
> another package requires isn''t really much better, you might as
well
> just add a Conflicts: and be done with it.
Unfortunately that''s not possible since all the libs that we need to 
depend on (libxenctrl, etc.) in xen-utils-4.1 depends on the package 
that install the udev rules (xen-utils-common).

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.
> In
>
http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2011-April/003362.html
the Debian package maintainer proposed a scheme by which xm and xl could
coexist. Adding "xapi" (or whichever other toolstack you are
considering) as an option to that scheme and having all the sets of hotplug
scripts check that their scheme is active seems like a reasonable solution to
me.
>
> Of course in the longer term we should attempt to converge the hotplug
> scripts of the different toolstacks into a single set of (e.g. libxl
> based) scripts.
Or realize that those scripts are an abomination in the first place and 
get rid of them.

-- 
Vincent

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

On Wed, 2011-06-08 at 21:33 +0100, Vincent Hanquez
wrote:
> On 06/08/2011 08:49 PM, Ian Campbell wrote:
> >> chmod -x and rm would do the same things (provided udev
isn''t unhappy),
> >> but modifying files of package A from another package B is highly
> >> frowned upon.
> >
> > Dropping down a file which unilaterally disables critical behaviour in
> > another package requires isn''t really much better, you might
as well
> > just add a Conflicts: and be done with it.
> 
> Unfortunately that''s not possible since all the libs that we need
to
> depend on (libxenctrl, etc.) in xen-utils-4.1 depends on the package 
> that install the udev rules (xen-utils-common).
and of course working with the maintainer of the package you wish to
integrate with is clearly out of the question?
> 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.

Ian.



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

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.

-- 
Vincent

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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/09/2011 10:23 AM, Ian Campbell wrote:
> Feel free to suggest patches which implement any better scheme you have.
>    
I did already.

My solution involves going to step 2 directly, keeping a simple way for 
compat toolstacks to still work dynamically in parallel with new more 
modern toolstack that doesn''t use those udev script. And eventually 
reach step 3 that will remove the udev scripts altogether (which render 
fancy tweaks in those udev scripts (step 1) absolutely moot)

Unfortunately you really want to go to step 1, before step 2 which 
involves doing lots of unnecessary work. I don''t have any interest in 
that as stated above.

-- 
Vincent

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

On Thu, 2011-06-09 at 11:07 +0100, Vincent Hanquez
wrote:
> On 06/09/2011 10:23 AM, Ian Campbell wrote:
> > Feel free to suggest patches which implement any better scheme you
have.
> >    
> 
> I did already.
> 
> My solution involves going to step 2 directly, keeping a simple way for 
> compat toolstacks to still work dynamically in parallel with new more 
> modern toolstack that doesn''t use those udev script.
No it does not go straight to any (completely undefined) step 2 and it
in no way allows toolstacks to dynamically work in parallel -- it allows
your current pet project to unilaterally disable functionality in other
existing toolstacks because that is convenient to you, without any
consideration for the bigger picture or actual _real_ interop with other
toolstacks or usecases.

Furthermore I object to your characterisation of some toolstacks as
"compat" and the one you are currently interested in as
"new"/"modern".
xl uses these udev scripts and is in no way a "compat" toolstack. You
cannot simply deny the existence of other toolstacks, ignore their
requirements and justify breaking their functionality by branding them
legacy.

Please step back and see that there is a bigger picture and other
considerations than whatever you are currently working on and the
quickest most expedient way to solve your issue at the expense of
everything else.
>  And eventually 
> reach step 3 that will remove the udev scripts altogether (which render 
> fancy tweaks in those udev scripts (step 1) absolutely moot)
So what is your proposal for removing the need for udev (i.e. what is
the so-called "step 3")? Unless you have specific concrete suggestions
then we cannot build consensus around any move away from the udev
scripts and all this talk is just hot air.

And, to be frank, unless you have an plan to back it up with patches
sooner rather than later (eventually is a long time) we are most likely
going to be using the udev script for the foreseeable future, since you
seem to be the only one who feels strongly about it. (I don''t know
perhaps your suggested approach will be so compelling that it will spur
someone else to implement it, fingers crossed).

Unless there is active movement towards "step 3" (whatever that is)
fixing the udev scripts to allow interop between toolstacks with other
udev scripts (or none at all) is hardly moot.
> Unfortunately you really want to go to step 1, before step 2 which 
> involves doing lots of unnecessary work. I don''t have any interest
in
> that as stated above.
You aren''t obliged to do any more work than you want. However it does
not follow that we must take your original patch.

Ian.


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

On 06/10/2011 08:13 AM, Ian Campbell wrote:
> No it does not go straight to any (completely undefined) step 2 and it
> in no way allows toolstacks to dynamically work in parallel -- it allows
> your current pet project to unilaterally disable functionality in other
> existing toolstacks because that is convenient to you, without any
> consideration for the bigger picture or actual _real_ interop with other
> toolstacks or usecases.
dynamic as in = can be installed on disk in parallel.

There''s no way to make two managed toolstacks run in parallel, so i 
wasn''t using dynamic in this sense. the only sense i''m talking
about is
that you could have start the init script for XCP or Xend (or xl), and 
it would have clear/set the dummy file to enable/disable the udev script 
depending on whether you want the udev script running or not which is a 
toolstack properties.

So let''s be clear, instead of having a way to interop which
isn''t great
(not "actual real interop" reusing your word), we have no interop 
whatsoever.
> Furthermore I object to your characterisation of some toolstacks as
> "compat" and the one you are currently interested in as
"new"/"modern".
> xl uses these udev scripts and is in no way a "compat" toolstack.
You
> cannot simply deny the existence of other toolstacks, ignore their
> requirements and justify breaking their functionality by branding them
> legacy.
I simply characterised the toolstacks using a the new/modern udev 
mechanism i''m talking about as new/modern. compared to the toolstack 
that use the old mechanism as compat, since this was an attempt to keep 
both mechanisms in. this is *not* about the toolstack itself nor about 
branding them legacy.
> So what is your proposal for removing the need for udev (i.e. what is
> the so-called "step 3")? Unless you have specific concrete
suggestions
> then we cannot build consensus around any move away from the udev
> scripts and all this talk is just hot air.
>
> And, to be frank, unless you have an plan to back it up with patches
> sooner rather than later[...]
This feature has been discussed with toolstack people, patch has been 
send to maintainers already and it''s about to be committed in one case 
(on two) provided it pass my tests i''ve left running over the weekend.
> You aren''t obliged to do any more work than you want. However it
does
> not follow that we must take your original patch.
Of course. I never implied as such. Now, Let''s give this thread and the
patch a rest.

-- 
Vincent

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

On Mon, 2011-06-13 at 09:58 +0100, Vincent Hanquez
wrote:
> There''s no way to make two managed toolstacks run in parallel, so
i
> wasn''t using dynamic in this sense. the only sense i''m
talking about
> is that you could have start the init script for XCP or Xend (or xl),
> and it would have clear/set the dummy file to enable/disable the udev
> script depending on whether you want the udev script running or not
> which is a toolstack properties.
Oh, right, that makes sense, more so than the cfg file based scheme I
suggested (although eventually I expect that the will be needed too to
express the admin''s wishes, that''s not relevant here). Thanks
for
explaining the actual usage.

I think we could make it opt-in for toolstacks which want it rather than
opt-out for those that don''t, since only xend and xl want them (I
think???) that seems like a manageable change. The xencommons initscript
might work for touching the file, but perhaps the xend initscript and
something internal to libxl/xl (which doesn''t have it''s own
initscript)
would be better. Only question is who removes it in the xl case.

Since the file is automatically managed I don''t think /etc is the right
place -- probably somewhere like /var/run (which handily gets it cleaned
up on reboot too).
> This feature has been discussed with toolstack people, patch has been 
> send to maintainers already and it''s about to be committed in one
case
> (on two) provided it pass my tests i''ve left running over the
weekend.
Sounds interesting, do you have a link? I didn''t see anything in the
xen-api archives, but perhaps it was elsewhere? (or is this a reference
some other toolstack?)

Ian.


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

On 06/14/2011 02:36 PM, Ian Campbell wrote:
> On Mon, 2011-06-13 at 09:58 +0100, Vincent Hanquez wrote:
> Oh, right, that makes sense, more so than the cfg file based scheme I
> suggested (although eventually I expect that the will be needed too to
> express the admin''s wishes, that''s not relevant here).
Thanks for
> explaining the actual usage.
Right, I guess i should have started with that. it would have same us both some 
time.
> I think we could make it opt-in for toolstacks which want it rather than
> opt-out for those that don''t, since only xend and xl want them (I
> think???) that seems like a manageable change. The xencommons initscript
> might work for touching the file, but perhaps the xend initscript and
> something internal to libxl/xl (which doesn''t have it''s
own initscript)
> would be better. Only question is who removes it in the xl case.
>
> Since the file is automatically managed I don''t think /etc is the
right
> place -- probably somewhere like /var/run (which handily gets it cleaned
> up on reboot too).
Yes. I don''t mind too much about the details, /run (with a fallback to
/var/run
for old distrib) is probably better indeed.

I''m not sure about xl, i had the idea that you have to switch away from
xend
when using xl by using an initscript. If that''s not the case, then
probably
something internal would work.
>> This feature has been discussed with toolstack people, patch has been
>> send to maintainers already and it''s about to be committed in
one case
>> (on two) provided it pass my tests i''ve left running over the
weekend.
>
> Sounds interesting, do you have a link? I didn''t see anything in
the
> xen-api archives, but perhaps it was elsewhere? (or is this a reference
> some other toolstack?)
No, unfortunately there''s no record of the discussion since we had it
directly.

The udev module has been merged in the XCP tree [1]; The "only" thing
left is
switching the hotplug module to be using this module. In XCI the full patch is 
in (but I don''t have any public link to it).

[1] 
https://github.com/xen-org/xen-api-libs/commit/d6db355a4df93fafcf42cfb05df92dbae6a3b8f2

-- 
Vincent

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

Ian Campbell writes ("Re: [Xen-devel] [PATCH] add a way to disable
xen''s udev script."):
> I think we could make it opt-in for toolstacks which want it rather than
> opt-out for those that don''t, since only xend and xl want them (I
> think???) that seems like a manageable change. The xencommons initscript
> might work for touching the file, but perhaps the xend initscript and
> something internal to libxl/xl (which doesn''t have it''s
own initscript)
> would be better. Only question is who removes it in the xl case.
xencommons seems like the right place to me at least for the moment.

If we want xencommons to do something more sophisticated it already
reads /etc/default/xen so it could look there to see which toolstack
was in use and decide accordingly whether to enable the udev scripts.
> Since the file is automatically managed I don''t think /etc is the
right
> place -- probably somewhere like /var/run (which handily gets it cleaned
> up on reboot too).
Yes.

Ian.

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