On Fri, Nov 25, 2005 at 03:55:37PM -0800, Dan Smith wrote:
>
> EM> Unfortunately, Xend is not the right place for these checks. We
> EM> have to worry about device configuration even when it's not
> EM> performed through Xend -- the drivers will configure the device if
> EM> you write to the store, even if you don't go through Xend. With
> EM> that in mind, these safety checks need to be lower down in the
> EM> system.
>
> I think the drivers should attach multiple DomUs to the same block
> device, if asked to do so. The bug description said that this
> functionality should be provided by the tools for special-purpose
> filesystems that can handle concurrent writers.
My fix includes an override to the test. By setting the mode to w!, you get
read-write access, with sharing allowed.
> It seems perfectly
> logical to me for the drivers to do what they're told, and have the
> tools (whatever tools may be in use) provide the checks and
> protections necessary to help the user from shooting himself in the
> foot.
To a certain extent, yes, but on the other hand, what you do by doing that is
require all tools to duplicate the same checks. In this case, the check is so
important (filesystems are easily corrupted without it) that the check would
definitely have to be included in every tool, so it is better to push it down
nearer the drivers, where it can be shared.
> Further, I think that pushing a bunch of checks into the hotplug
> scripts is less desirable, as it makes it harder to communicate good
> information back to the frontend tools. Right now, we just get a
> "failed" message instead of "device missing" or "device already in
> use" message.
My changes today add support for a hotplug-error node, which includes a full
error description. If you mount a filesystem in dom0 and then try to use the
same as a device in a guest, you will get the message:
Error: Device 2049 (vbd) could not be connected.
Device /dev/VG_XenRT/LV0 is mounted in the privileged domain,
and so cannot be mounted by a guest.
which is a lot better than some of Xend's other messages.
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home