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

[Blue Swirl]

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.

>
>>> 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.

>
>>> Comments?