> The hotplugs scripts are called from a udev rule but the event is
> triggered (asynchronously) by the backend driver based upon the changing
> state node, so ultimately they are triggered from the same xenstore
> watch.
>
> It's certainly possible that the sequencing is different between Linux
> and NetBSD or that in the Linux case there is some interlock (deliberate
> or otherwise) between the kernel side and the hotplug script side which
> saves our bacon.
>
> Who is responsible for driving the backend xenstore state machine under
> NetBSD? It doesn't look like xenbackendd (which just reacts to state
> changes).
xbdback is responsible for changing the state of xenstore, it performs
the state change and attaches devices to guests. It is pretty similar
to xenbackendd, but runs in the kernel space.
> Ah, that may well be it. I had thought that vnd was all in kernel but
> now I see that it is setup and torn down in the hotplug script, much
> like for loopback on Linux with xend.
It's basically the same strategy as the one used on Linux with loopback devices
> On Linux we were able to make the simplifying assumption of not handling
> this for phy devices because we had blktap to fall back on. NetBSD
> doesn't currently have that option.
Well, I'm trying to implement something similar to blktap2 in NetBSD,
but all in user space, using pud, a driver that enables the
implementation of block and character device drivers as userspace
daemons (something similar to nbd in Linux I think), I've also looked
into FUSE, but it required the use of vnd/loop device for the image to
be presented as a block device.
> I think part of the problem is that the vbd lifecycle and the backing
> device's lifecycle (vnd in this case, but could also be an iscsi login
> for example) are somewhat entwined via the hotplug scripts etc when
> really they should be layered and somewhat independent.
>
> Ian Jackson has the best handle on this stuff and I know he has plans to
> move the block script callout stuff forward to better support various
> more complex block device types, integrate better with the toolstack and
> generally rationalise the existing interfaces etc so I'd like to hear
> what he thinks before I suggesting any particular avenue of attack to
> this problem. He's travelling right now but may be online intermittently
> next week (we're both going to be at the Debian conference in Banja
> Luka), I think he's back properly the week after that though.
>
> I'm travelling next week and on vacation the week after. But I need to
> get onto this soon so it is done for Xen 4.2, since it will an API
> incompatible change to libxl and we are hoping to declare the API stable
> at that point.
Well, I hope you had a good trip, I will be off next week, and won't
be back until the 10th of August, so we will have to leave this on a
hold until then, but I'm not going to let it die.
> Have you considered coming to the Munich Xen.org hackathon in September?
> http://wiki.xen.org/xenwiki/MUC_2011_hackathon. That would be a great
> opportunity to work through some of these issues and ensure that the
> future direction of libxl's handling of this stuff works for NetBSD as
> well as Linux.
Thanks for the offer, I would really like to come, but I have some
other stuff I also have to attend, so I don't think I will be able to
come (it took me so long to answer this email because I was trying to
come to the hackathon). Anyway, I hope I can come to future
meetings/hackathons! I don't know if Christoph will we able to attend,
if so he may be able to clarify some of the doubts about NetBSD device
handling.
Thanks and regards, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home