Re: [Xen-devel] [Patch 3/7] pvSCSI driver

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> > Of course, we might be able to declare the tree stable except for SCSI
> > support, but that's a bit of a change from our current model.
>
> The pieces of pvSCSI are (I think):
> . xend changes
> . scripts in /etc/xen/scripts
> . linux backend
> . linux frontend
>
> The linux backend and linux frontend could be built as modules outside
> of the main linux tree (eg just with linux-headers-2.6.18 under Debian -
> I've done this for the backend at least).
>
> The scripts can be added easily enough.

I was wondering if we could follow the kernel.org Linux policy of marking the 
drivers EXPERIMENTAL until the interface had stabilised.  The problem there 
is possibly that the interface headers would also be in the Xen tree, where 
we don't have a way of marking stuff in that way...  If the only user is 
Linux, maybe it doesn't matter.

FWIW kernel.org occasionally exposes non-stable interfaces to userspace with a 
warning not to use them (not ideal practice though).

> Would it be possible to add a plugin functionality to xend and the
> supporting libraries? If so, then it becomes very easy to build it all
> without having to worry so much about getting it in to the main tree...

You'd need to add some kind of plugin support to both Xend and xm separately, 
The Xend one would do the business of accepting configuration details and 
setting up the pvSCSI channel.  The xm one would add config file parsing for 
pvSCSI and send the requests to Xend.

It certainly doesn't seem like it would be conceptually hard to fit into the 
model already used by Xend.  It's harder to say just how difficult it'd be to 
shoehorn into the code but I wouldn't have thought it'd actually need to be 
*that* big a change.  Python is actually rather well suited for this sort of 
thing.

The original Xend architecture was IIRC designed from almost the start to make 
plugin-type operation with code reuse fairly easy, which was a good decision 
and is partly why the code was an initial jump in complexity.  That 
modularity has been largely retained in the design, I think; it might make 
sense for somebody to look more closely at plugin-ifying Xend.  It'd make it 
easier for external developers to add device types, and it'd mean 
experimental device channels could be easily tested before merge into 
mainline Xen.

Cheers,
Mark

-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)

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