On 22/03/16 12:52, Roger Pau Monné wrote:
> On Mon, 21 Mar 2016, George Dunlap wrote:
>> Signed-off-by: George Dunlap <george.dun...@citrix.com>
>> ---
>> Changes since v1:
>> - Attempt to make a clear distinction between custom hotplug scripts
>> and the script called for raw physical devices and files
>>
>> CC: Ian Jackson <ian.jack...@citrix.com>
>> CC: Wei Liu <wei.l...@citrix.com>
>> CC: Roger Pau Monne <roger....@citrix.com>
>> ---
>> docs/misc/block-scripts.txt | 101
>> ++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 101 insertions(+)
>>
>> diff --git a/docs/misc/block-scripts.txt b/docs/misc/block-scripts.txt
>> new file mode 100644
>> index 0000000..6dd5d48
>> --- /dev/null
>> +++ b/docs/misc/block-scripts.txt
>> @@ -0,0 +1,101 @@
> [...]
>> +Inputs
>> +------
>> +
>> +In all cases, the scripts are called with either "add" or "remove" as
>> +the command. For custom scripts, the command will be the first
>> +argument of the script (i.e. $1).
>> +
>> +The environment variable XENBUS_PATH will be set to the
>> +path for the block device to be created.
>
> This is true for Linux, but not for NetBSD. On NetBSD no env variables are
> needed, and everything is passed as arguments using the following format:
>
> ./<script> <backend_path> <xenbus state>
>
> Where xenbus state is either 2 or 6.
>
> On FreeBSD I'm aiming of using the same input interface for both block and
> network scripts, and it is the following:
>
> ./<script> {add/remove} <backend path>
>
> With no env variables provided at all. So either this section is expanded,
> or it is labelled as "Linux Inputs".
Nothing like consistency across implementations. :-)
So in the case of NetBSD, "2" means 'add' and "6" means 'remove'? Or
how does that work?
Presumably there's not much we can do about NetBSD at this point, if
there are (or may be) out-of-tree scripts that expect the new format.
But unless there's a good reason, it seems like we should try to
converge the hotplug script protocol.
Was there a particular reason you wanted to use an argument instead of
an environment variable? If not, it's probably better to just follow
suit with the Linux protocol.
If there is a good reason, we could consider changing the Linux protocol
as well (leaving the environment variable in for backwards-compatibility
purposes).
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
