[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO |
Date: |
Wed, 2 May 2012 20:39:47 +0200 |
On 02.05.2012, at 17:57, Stefan Weinhuber <address@hidden> wrote:
> On 2012-05-02 16:27, Christian Borntraeger wrote:
>> On 02/05/12 14:54, Alexander Graf wrote:
>>> On 05/02/2012 01:38 PM, Paolo Bonzini wrote:
>>>>> On 05/02/2012 01:26 PM, Paolo Bonzini wrote:
>>>>>>> and everyone should be happy :). I would really like to have as
>>>>>>> little #ifdef TARGET_S390 code in QEMU. And #ifdef __s390__ is
>>>>>>> even worse,
>>>>>>> as it means we won't be able to execise that code path on other
>>>>>>> architectures.
>>>>>> True, but how do you exercise that code path with DASD geometry
>>>>>> on !__s390__?
>>>>> If we make things a flag for the guessing code, it should work just
>>>>> as well with image files, right?
>>>> Only when they're not blank. :) I was only thinking of #ifdef __s390__
>>>> for the call to HDIO_GETGEO.
>>>
>>> Well, if guessing is a function
>>>
>>> guess_size(disk_size, block_size)
>>>
>>> then we would be able to do the same on an image file. Christian, would
>>> that work?
>>
>> I think that the geometry values can not always be guessed correctly based on
>> block_size and disk_size.
>>
>> Stefan, can you clarify that?
>>
>> If we cannot reliably guess the geometry based on blocksize and size, I
>> still think
>> that we should use the host values, e.g. after checking that BIODASDINFO2
>> returns
>> successfully.
>
> If we know the device type (e.g. 3390) and the block_size, then we can
> compute the number of blocks per track. The number of tracks per cylinder is
> a given (15) and the number of cylinders can be computed from these numbers
> and the disk_size.
>
> How do we get the device type? I think we could get away with restricting
> ECKD DASDs to type 3390, but even then, how would we distinguish an ECKD DASD
> from anything else, e.g. a SCSI device?
>
> We could simply attempt the above cylinder calculation for every device and
> if we get a result without a remainder we just assume that we have a DASD.
> This could lead to false positives, but maybe that is acceptable?
We could add a parameter to the disk configuration like type=dasd (default
would be type=auto) which tells the geometry detection code to assume a 3390.
If type == auto, we try a dasd ioctl and if that works use type=dasd.
That way you could easily create a dump of the disk and get it working with a
simple type=dasd. Later we could even add dasd disk label detection code which
defaults type=auto to dasd if it finds one.
That way disk images should be as easy to use as real dasd devices :).
Alex
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Christian Borntraeger, 2012/05/02
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Alexander Graf, 2012/05/02
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Paolo Bonzini, 2012/05/02
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Alexander Graf, 2012/05/02
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Paolo Bonzini, 2012/05/02
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Alexander Graf, 2012/05/02
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Christian Borntraeger, 2012/05/02
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Alexander Graf, 2012/05/02
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Christian Borntraeger, 2012/05/02
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Stefan Weinhuber, 2012/05/02
- Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO,
Alexander Graf <=
Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO, Christian Borntraeger, 2012/05/02