| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [patch 20/20] XEN-paravirt: Add Xen virtual block device
|
To: |
Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
|
Subject: |
[Xen-devel] Re: [patch 20/20] XEN-paravirt: Add Xen virtual block device driver. |
|
From: |
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> |
|
Date: |
Sun, 14 Jan 2007 12:37:46 +0000 |
|
Cc: |
Andrew Morton <akpm@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Pratt <ian.pratt@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx |
|
Delivery-date: |
Sun, 14 Jan 2007 04:38:39 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<Pine.LNX.4.61.0701141202050.26276@xxxxxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
Acc32MrnCbWgRqPMEdur9wANk04WTA== |
|
Thread-topic: |
[patch 20/20] XEN-paravirt: Add Xen virtual block device driver. |
|
User-agent: |
Microsoft-Entourage/11.3.2.061213 |
On 14/1/07 11:05 am, "Jan Engelhardt" <jengelh@xxxxxxxxxxxxxxx> wrote:
>> The block device frontend driver allows the kernel to access block
>> devices exported exported by a virtual machine containing a physical
>> block device driver.
>
> Is this significantly different from ubd/hostfs that it actually warrants a
> reinvention?
It is certainly unlike hostfs because hostfs provides file-level access to
host storage, not block-level. It's unlike both ubd and hostfs in that both
of those (I believe) make significant use of the syscall interface (and so
assume they run in a process on a Linux host). Also our driver appears to be
lower level, pushing more responsibility for features like CoW into the VMM.
Arguably that's a more generically reusable and flexible strategy although
it requires more VMM run-time support (which a Xen system provides).
>> + (void)xenbus_switch_state(info->xbdev, XenbusStateConnected);
>
> Cast remove, if xenbus_switch_state does not have __must_check.
> Also elsewhere.
Okay, we should certainly follow the general rule here.
Thanks,
Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home