Re: [Xen-devel] Handling iSCSI block devices (Was: Driver domains and device handling)

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Roger Pau Monne writes ("Re: Handling iSCSI block devices (Was: Driver domains 
and device handling)"):
> I was thinking of adding a new variable to aodev that can contain an
> extra parameter to pass to hotplug scripts, so we can directly pass the
> full diskspec to the hotplug script and the hotplug script itself can
> decide what to save in the "params" field (to be used later in the
> shutdown/destroy).

That's all very well but command line parameters are visible in ps and
so not suitable for passwords.  Really there should be an area in
xenstore that's for communication between the toolstack and the driver
domain (including scripts in the latter), but which is not visible to
the guest.

> > So how would we tell whether the script understood this ?
> 
> I'm still looking into the current hotplug script mess, but I only see
> the following lines in block-common.sh that should be changed:
> 
> if [ "$command" != "add" ] &&
>    [ "$command" != "remove" ]

What about existing out-of-tree scripts ?  Do they all use
block-common ?

> then
>   log err "Invalid command: $command"
>   exit 1
> fi

And this is no good because if libxl does the error handling properly
it would cause every attempt to fail :-).  You could explicitly ignore
prepare and unprepare.

> I think current block hotplug scripts will work nicely when passed the
> "prepare" command, they will become no-ops, since they all seem to use
> the following case:

I'm worried about out-of-tree scripts.


The existing hotplug script interface is pretty horrible TBH.  Which
is why I was suggesting inventing a new one.  We could keep the old
interface for out-of-tree and unconverted in-tree scripts, and provide
a new parameter to request the new style.

Eg "method=<something>" rather than "script=<something>" would mean
"set script to <something> and also set the flag saying `use the new
script calling convention'"

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel