[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
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
Main Index |
Thread Index |