Re: [Xen-devel] [PATCH v2 0/3] Add support for NetBSD gntdev

[Toby Karyadi <toby.karyadi@xxxxxxxxx>]

Whoops, this was meant to be a correspondence just for Manuel. But since 
the cat is out of the bag...
On 12/3/12 4:34 PM, Roger Pau Monné wrote:
> I don't understand this whole argument about "policy vs 
> functionality", from my point of view what we have now is also a 
> policy, every raw disk file is attached using the vnd device. And 
> getting a gntdev isn't certainly a policy, on the other hand this is 
> going to get us much more functionality (like the ability to run 
> backends in userspace, for example support for blktap3 when it is 
> released). 
Yes, on netbsd file: disk config will use vnd, but only because the way 
the block script is written. The functionality of the block script is 
well defined, and therefore is much easier to override, then, say 
patching libxl. Therefore, it's not a 'policy', but more of a default 
functionality, since anyone who has some knowledge about shell script 
can modify it to do something else, e.g. run the vnd under rump (is that 
possible?) to avoid dom0 blowing up.
But if it is decided that disk config that begins with file: to always 
use qemu-dm just because on the off chance that using vnd over NFS can 
blow up the dom0, and if there is no way to override it, or really 
difficult (which is relative, I know), then it becomes a  'policy'. Can 
I setup iscsi through hotplug for example?
 To be honest, I haven't look into how the hotplug script works, so 
hopefully it can provide equivalent functionality and flexibility.
> > Again, as discused with Manuel, a better solution has to be found for
> > this issue, and I'm sure we can reach a consensus.
That's what I'm hoping.
> The retirement of xenbackendd is done for a good reason, calling 
> hotplug scripts from libxl allows for better control of when hotplug 
> scripts are called, and also allows for better error handling if these 
> scripts fail. Same scripts are called, so functionality stays the 
> same. This was done for both NetBSD and Linux, in the past Linux used 
> to call hotplug scripts from udev, and now they are called from libxl 
> too. I'm not able to see how having a more unified hotplug script 
> interface can be a bad thing. Again, I'm not able to see how this is a 
> problem, in the past you had xend, which was a gigantic piece of 
> python code acting as a central arbiter, now you have a small C daemon 
> for each running domain. libxl is generally considered a better piece 
> of code, and is much more easier to maintain than xend. Do you have 
> any concrete technical reason to belive that xend was better than libxl? 
Like I said, I probably look into the hotplug script framework before I 
yammer any further. If it allows for overriding file: disk configs with 
vnd or whatever, then I'm happy. I don't think xend is better than 
libxl, on the contrary, I find libxl source to be more understandable, 
and much smaller. I couldn't make out head from tail with xend source 
code and I'm a python programmer most of the time. But by the same token 
I know I've got this blob called xend that does these specific things, 
and xenbackendd that does these specific things. There is really nothing 
that prevents from say creating another program called domu_watcher (or 
whatever) that is linked to libxl for functionality sharing and gets 
launched by xl during xl create; but again, this is more nitpicks and a 
matter of preference.
> libxl has even split OS specific routines in separate files, both for 
> Linux and NetBSD and frankly, I'm not able to see how that is worse 
> that the amount of patches we had in pkgsrc to have xend working. Now 
> libxl works out-of-the-box on NetBSD, and many efforts have been put 
> into that. We should focus our efforts on getting Xen to work on 
> NetBSD without a ton of NetBSD specific out of the tree patches, and 
> right now my biggest concern is getting Qemu upstream working. 
I noticed that even in 4.1.2, which I thought was a good start, however 
those compile-time 'plugins' were not useful back then since it was only 
for whether blktap is supported, to which under netbsd compilation the 
answer is 'nah!'. I haven't looked into 4.2 libxl src either, so maybe 
the plugin points are much extensive now. I know enough that creating a 
system with plugin support, whether compile-time or during runtime, is 
not easy, because to a certain degree you have to expect the unexpected. 
If I sound I'm just griping all of the time, it's just that I had more 
time right now to jump in, but I don't. So, I do a lot of hand waving 
;-). I understand that you gotta get qemu working, but that's orthogonal 
to letting us shoot ourselves in the foot ;-) I mean, have you used 
netbsd's disklabel?
Anyways...

Cheers,
Toby

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