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