Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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?



Home | Main Index | Thread Index | Old Index