Blue Swirl <blauwir...@gmail.com> writes: > On Wed, Jun 20, 2012 at 8:21 AM, Markus Armbruster <arm...@redhat.com> wrote: >> Blue Swirl <blauwir...@gmail.com> writes: >> >>> On Tue, Jun 19, 2012 at 7:45 AM, Markus Armbruster <arm...@redhat.com> >>> wrote: >>>> Blue Swirl <blauwir...@gmail.com> writes: >>>> >>>>> On Mon, Jun 18, 2012 at 9:10 AM, Markus Armbruster <arm...@redhat.com> >>>>> 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.
