Re: [Xen-devel] [PATCH net-next] xen-netback: get rid of old udev related code

["Durrant, Paul" <pdurrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jürgen Groß <jgross@xxxxxxxx>
> Sent: 13 December 2019 05:41
> To: David Miller <davem@xxxxxxxxxxxxx>; Durrant, Paul
> <pdurrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; wei.liu@xxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: get rid of old udev
> related code
> 
> On 12.12.19 20:05, David Miller wrote:
> > From: Paul Durrant <pdurrant@xxxxxxxxxx>
> > Date: Thu, 12 Dec 2019 13:54:06 +0000
> >
> >> In the past it used to be the case that the Xen toolstack relied upon
> >> udev to execute backend hotplug scripts. However this has not been the
> >> case for many releases now and removal of the associated code in
> >> xen-netback shortens the source by more than 100 lines, and removes
> much
> >> complexity in the interaction with the xenstore backend state.
> >>
> >> NOTE: xen-netback is the only xenbus driver to have a functional
> uevent()
> >>        method. The only other driver to have a method at all is
> >>        pvcalls-back, and currently pvcalls_back_uevent() simply returns
> 0.
> >>        Hence this patch also facilitates further cleanup.
> >>
> >> Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx>
> >
> > If userspace ever used this stuff, I seriously doubt you can remove this
> > even if it hasn't been used in 5+ years.
> 
> Hmm, depends.
> 
> This has been used by Xen tools in dom0 only. If the last usage has been
> in a Xen version which is no longer able to run with current Linux in
> dom0 it could be removed. But I guess this would have to be a rather old
> version of Xen (like 3.x?).
> 
> Paul, can you give a hint since which Xen version the toolstack no
> longer relies on udev to start the hotplug scripts?
> 

The udev rules were in a file called tools/hotplug/Linux/xen-backend.rules (in 
xen.git), and a commit from Roger removed the NIC rules in 2012:

commit 57ad6afe2a08a03c40bcd336bfb27e008e1d3e53
Author: Roger Pau Monne <roger.pau@xxxxxxxxxx>
Date:   Thu Jul 26 16:47:35 2012 +0100

    libxl: call hotplug scripts for nic devices from libxl

    Since most of the needed work is already done in previous patches,
    this patch only contains the necessary code to call hotplug scripts
    for nic devices, that should be called when the device is added or
    removed from a guest.

    Added another parameter to libxl__get_hotplug_script_info, that is
    used to know the number of times hotplug scripts have been called for
    that device. This is currently used by IOEMU nics on Linux.

    Signed-off-by: Roger Pau Monne <roger.pau@xxxxxxxxxx>
    Acked-by: Ian Jackson<ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

The last commit I could find to that file modified its name to 
xen-backend.rules.in, and this was finally removed by George in 2015:

commit 2ba368d13893402b2f1fb3c283ddcc714659dd9b
Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
Date:   Mon Jul 6 11:51:39 2015 +0100

    libxl: Remove linux udev rules

    They are no longer needed, having been replaced by a daemon for
    driverdomains which will run scripts as necessary.

    Worse yet, they seem to be broken for script-based block devices, such
    as block-iscsi.  This wouldn't matter so much if they were never run
    by default; but if you run block-attach without having created a
    domain, then the appropriate node to disable running udev scripts will
    not have been written yet, and the attach will silently fail.

    Rather than try to sort out that issue, just remove them entirely.

    Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

So, I think this means anyone using a version of the Xen tools within recent 
memory will be having their hotplug scripts called directly by libxl (and 
having udev rules present would actually be counter-productive, as George's 
commit states and as I discovered the hard way when the change was originally 
made).

  Paul



> 
> Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel