Daniel P. Berrange wrote:
>> enum {
>> -VIR_STORAGE_POOL_NETFS_AUTO = 0,
>> +VIR_STORAGE_POOL_NETFS_UNKNOWN = 0,
>> +VIR_STORAGE_POOL_NETFS_AUTO = 1,
>> VIR_STORAGE_POOL_NETFS_NFS,
>> +VIR_STORAGE_POOL_NETFS_LAST,
>> };
>
> I missed that one last time around - no need for "u
Chris Lalancette <[EMAIL PROTECTED]> wrote:
> Daniel P. Berrange wrote:
>>> diff -u -r1.15 storage_backend_fs.c
>>> --- a/src/storage_backend_fs.c 13 Oct 2008 16:46:29 - 1.15
>>> +++ b/src/storage_backend_fs.c 16 Oct 2008 12:31:23 -
>>> @@ -48,7 +48,8 @@
>>> #include "xml.h"
On Thu, Oct 16, 2008 at 03:47:26PM +0200, Chris Lalancette wrote:
> Daniel P. Berrange wrote:
> >> diff -u -r1.15 storage_backend_fs.c
> >> --- a/src/storage_backend_fs.c 13 Oct 2008 16:46:29 - 1.15
> >> +++ b/src/storage_backend_fs.c 16 Oct 2008 12:31:23 -
> >> @@ -48,7 +48,8
Daniel P. Berrange wrote:
>> diff -u -r1.15 storage_backend_fs.c
>> --- a/src/storage_backend_fs.c 13 Oct 2008 16:46:29 - 1.15
>> +++ b/src/storage_backend_fs.c 16 Oct 2008 12:31:23 -
>> @@ -48,7 +48,8 @@
>> #include "xml.h"
>>
>> enum {
>> -VIR_STORAGE_POOL_FS_AUTO
Chris Lalancette <[EMAIL PROTECTED]> wrote:
> Daniel P. Berrange wrote:
>> I know you're just replicating the existing code, but both these functions
>> can
>> be killed off and replaced with auto-generated code from our enum support
>> macros
>>
>> VIR_ENUM_IMPL(virStorageBackendDiskLabel,
>>
On Thu, Oct 16, 2008 at 02:35:21PM +0200, Chris Lalancette wrote:
> Daniel P. Berrange wrote:
> > I know you're just replicating the existing code, but both these functions
> > can
> > be killed off and replaced with auto-generated code from our enum support
> > macros
> >
> > VIR_ENUM_IMPL(v
Daniel P. Berrange wrote:
> I know you're just replicating the existing code, but both these functions can
> be killed off and replaced with auto-generated code from our enum support
> macros
>
> VIR_ENUM_IMPL(virStorageBackendDiskLabel,
> VIR_STORAGE_POOL_DISK_LAST,
>
"Daniel P. Berrange" <[EMAIL PROTECTED]> wrote:
>> +struct diskType disk_types[] = {
>
> This can be const const - surprised Jim didn't catch this :-)
> +struct diskType disk_types[] = {
Had to leave some for you. :-P
Now that you mention it, though, that should be "static", too.
>> +enum partT
Daniel P. Berrange wrote:
>
> I don't understand why it has to be 1-billion ? For the enum support to
> work correctly, we need this to be contiguous, starting from zero, and
> and as the last element have
>
> VIR_STORAGE_POOL_DISK_LAST
>
> This perhaps suggests that DISK_UNKNOWN should
On Thu, Oct 16, 2008 at 11:52:48AM +0200, Chris Lalancette wrote:
> Chris Lalancette wrote:
> > To support LVM partitioning in oVirt, one of the things we need is the
> > ability
> > to tell what kind of label is currently on a block device. Here, a 'label'
> > is
> > used in the same sense that
On Thu, Oct 16, 2008 at 09:43:58AM +0200, Chris Lalancette wrote:
> To keep code duplication down, I moved some of the enum's from
> storage_backend_disk.c into a common place. Note, however, that there is a
> slight semantic change because of this. Previously, if no label was found on
> a
> dis
Chris Lalancette wrote:
> To support LVM partitioning in oVirt, one of the things we need is the ability
> to tell what kind of label is currently on a block device. Here, a 'label' is
> used in the same sense that it is used in parted; namely, it defines which
> kind
> of partition table is on t
Daniel Veillard wrote:
>
> Patch looks fine to me +1
> I wonder what happens when you hit a block device which had no label
> or partition table, and has a raw file system on it directly. I
> sometimes do that by mistake on USB devices but the kernel still manage
> to handle them ... sometime
Jim Meyering wrote:
>> diff -u -r1.21 storage_backend.c
>> --- src/storage_backend.c5 Sep 2008 12:03:45 - 1.21
>> +++ src/storage_backend.c16 Oct 2008 07:29:46 -
>> @@ -192,6 +192,30 @@
>> return ret;
>> }
>>
>> +struct diskType disk_types[] = {
>> +{ "lvm2", VIR_STO
On Thu, Oct 16, 2008 at 09:43:58AM +0200, Chris Lalancette wrote:
> To support LVM partitioning in oVirt, one of the things we need is the ability
> to tell what kind of label is currently on a block device. Here, a 'label' is
> used in the same sense that it is used in parted; namely, it defines
Chris Lalancette <[EMAIL PROTECTED]> wrote:
> To support LVM partitioning in oVirt, one of the things we need is the ability
> to tell what kind of label is currently on a block device. Here, a 'label' is
> used in the same sense that it is used in parted; namely, it defines which
> kind
> of par
To support LVM partitioning in oVirt, one of the things we need is the ability
to tell what kind of label is currently on a block device. Here, a 'label' is
used in the same sense that it is used in parted; namely, it defines which kind
of partition table is on the disk, whether it be DOS, LVM2, S
17 matches
Mail list logo
