On 02.05.2012, at 17:57, Stefan Weinhuber <w...@linux.vnet.ibm.com> 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