Re: [Qemu-devel] [PATCH 2/2] fdc: Move floppy geometry guessing back from block.c

[Markus Armbruster]

Blue Swirl <address@hidden> writes:

> On Wed, Jun 20, 2012 at 8:21 AM, Markus Armbruster <address@hidden> wrote:
>> Blue Swirl <address@hidden> writes:
>>
>>> On Tue, Jun 19, 2012 at 7:45 AM, Markus Armbruster <address@hidden> wrote:
>>>> Blue Swirl <address@hidden> writes:
>>>>
>>>>> On Mon, Jun 18, 2012 at 9:10 AM, Markus Armbruster <address@hidden> wrote:
>>>>>> Commit 5bbdbb46 moved it to block.c because "other geometry guessing
>>>>>> functions already reside in block.c".  Device-specific functionality
>>>>>> should be kept in device code, not the block layer.  Move it back.
>>>>>
>>>>> As discussed earlier, this is media specific, not device specific
>>>>> (except FDriveType). How about media.c?
>>>>
>>>> It's floppy-(media-)specific, isn't it?
>>>>
>>>> We discussed separating floppy drive emulation (fdd) from floppy
>>>> controller emulation.  Right now, they're mixed up in qdevs isa-fdc,
>>>> sysbus-fdc and SUNW,fdtwo.  Separating fdd involves splitting up those
>>>> qdevs.  I tried, but ran into QOM infrastructure difficulties.  Since
>>>> that part of QOM is being improved, I decided to postpone the splitting
>>>> work for a bit.
>>>>
>>>> I don't remember discussing a separation of floppy drive and floppy
>>>> media emulation.
>>>
>>> OK, maybe I mixed things up. How I see this is that a floppy drive may
>>> support several different media types, like 720k, 1.44M and 2.88M
>>> floppies, while floppy media may still be formatted differently with
>>> various number of sectors.
>>
>> Yes, there are several types of floppy drives, each capable of dealing
>> with a certain set of media geometries.
>>
>>>                            The media part is similar to CHS for hard
>>> disks, while the drive or type parts are not visible outside of the HD
>>> unit.
>>
>> Hard disk geometry is a property of the device, like floppy drive type,
>> but unlike floppy geometry.
>
> I guess the hard disk situation is internally not unlike to floppies
> at all, the manufacturer probably uses the same mechanisms and
> electronics for several drive models, only the platter capacity (with
> the tracks, heads and sectors like floppies) and related configuration
> changes. But for the end user, this is not visible and even the CHS
> can be fake if the drive can for example remap bad sectors or use some
> platter areas for internal use. Of course users are not able to
> exchange platters at will.

Makes sense, but we can ignore such hard disk internals in QEMU.

>>>> Related project: moving hard disk geometry out of the block layer.
>>>> Can't move into a device model, because we have three of them sporting
>>>> geometry: IDE, SCSI and virtio disks.  I guess I'll move them into a new
>>>> file in hw/.  media.c doesn't sound right for hard disks.  disk-geo.c?
>>>
>>> hd-geometry.c?
>>
>> Sold.
>>
>>>> I could move floppy geometry to the same file.  But there's zero overlap
>>>> between hard disk and floppy disk geometry, and the only consumer of
>>>> floppy geometry is the floppy disk device.  I don't expect that to
>>>> change, and that's why I'd prefer to make floppy geometry an
>>>> implementation detail of the floppy disk device, and hide it in fdc.c
>>>> now, fdd.c after the split.
>>>>
>>>> But if you insist, I can unhide it.
>>>
>>> How about fd-geometry.c and hd-geometry.c? Or chs-translation.c to
>>> combine both, maybe also other transformations of CHS to linear offset
>>> later?
>>
>> Since there's no overlap between hard and floppy disk geometry, I'd
>> rather not mix them up in the same file.
>>
>> Can do fd-geometry.c.  While I can't see what putting floppy geometry in
>> fd-geometry.c rather than next to its only user buys us (apart from
>> external linkage), I'll comply with your wish.
>
> On second thought, fd-geometry.c would not be used for anything else
> (until we have Jaz? Zip?), so merging it with fdc.c makes sense. I'm
> not sure the same also applies to hd-geometry.c.

We agree, excellent.  I'll put the floppy geometry code next to its only
user, with the understanding that we'll move it to its own file as soon
as a second user shows up.  The hard disk geometry code goes into
hw/hd-geometry.c.