qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO


From: Stefan Weinhuber
Subject: Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO
Date: Wed, 02 May 2012 17:57:18 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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?

Stefan Weinhuber




reply via email to

[Prev in Thread] Current Thread [Next in Thread]