John Snow <js...@redhat.com> writes:

> This allows us to distinguish between the current disk type and the
> current drive type. The drive is what's reported to CMOS, the disk is
> whatever the pick_geometry function suspects has been inserted.
>
> The drive field maintains the exact same meaning as it did previously,
> however pick_geometry/fd_revalidate will be refactored to *never* update
> the drive field, considering it frozen in-place during an earlier
> initialization call.
>
> Before this patch, pick_geometry/fd_revalidate could only change the
> drive field when it was FDRIVE_DRV_NONE, which indicated that we had
> not yet reported our drive type to CMOS. After we "pick one," even
> though pick_geometry/fd_revalidate re-set drv->drive, it should always
> be the same as the value going into these calls, so it is effectively
> already static.
>
> As of this patch, disk and drive will always be the same, but that may
> not be true by the end of this series.
>
> Disk does not need to be migrated because it is not user-visible state
> nor is it currently used for any calculations. It is purely informative,
> and will be rebuilt automatically via fd_revalidate on the new host.
>
> Signed-off-by: John Snow <js...@redhat.com>
> ---
>  hw/block/fdc.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/hw/block/fdc.c b/hw/block/fdc.c
> index 09bb63d..13fef23 100644
> --- a/hw/block/fdc.c
> +++ b/hw/block/fdc.c
> @@ -133,7 +133,8 @@ typedef struct FDrive {
   typedef struct FDrive {
>      FDCtrl *fdctrl;
>      BlockBackend *blk;
>      /* Drive status */
> -    FDriveType drive;
> +    FDriveType drive;         /* CMOS drive type */
> +    FDriveType disk;          /* Current disk type */

where

   typedef enum FDriveType {
       FDRIVE_DRV_144  = 0x00,   /* 1.44 MB 3"5 drive      */
       FDRIVE_DRV_288  = 0x01,   /* 2.88 MB 3"5 drive      */
       FDRIVE_DRV_120  = 0x02,   /* 1.2  MB 5"25 drive     */
       FDRIVE_DRV_NONE = 0x03,   /* No drive connected     */
   } FDriveType;

FDriveType makes obvious sense as drive type.

>      uint8_t perpendicular;    /* 2.88 MB access mode    */

If I understand @perpendicular correctly, it's just an extra hoop a
driver needs to jump through to actually access a 2.88M disk.

>      /* Position */
>      uint8_t head;
       uint8_t track;
       uint8_t sect;
       /* Media */

Shouldn't @disk go here?

       FDiskFlags flags;
       uint8_t last_sect;        /* Nb sector per track    */
       uint8_t max_track;        /* Nb of tracks           */
       uint16_t bps;             /* Bytes per sector       */
       uint8_t ro;               /* Is read-only           */
       uint8_t media_changed;    /* Is media changed       */
       uint8_t media_rate;       /* Data rate of medium    */

       bool media_inserted;      /* Is there a medium in the tray */
   } FDrive;

A disk / medium is characterised by it's form factor, density /
FDriveRate, #sides, #tracks, #sectors per track, and a read-only bit
(ignoring a few details that don't interest us).  Obviously, the drive
type restricts possible disk types.

What does @disk add over the media description we already have?

Aside: @bps appears to be write-only, and the value written looks odd.

> @@ -157,6 +158,7 @@ static void fd_init(FDrive *drv)
>      drv->drive = FDRIVE_DRV_NONE;
>      drv->perpendicular = 0;
>      /* Disk */
> +    drv->disk = FDRIVE_DRV_NONE;
>      drv->last_sect = 0;
>      drv->max_track = 0;
>  }
> @@ -286,6 +288,7 @@ static void pick_geometry(FDrive *drv)
>      drv->max_track = parse->max_track;
>      drv->last_sect = parse->last_sect;
>      drv->drive = parse->drive;
> +    drv->disk = drv->media_inserted ? parse->drive : FDRIVE_DRV_NONE;
>      drv->media_rate = parse->rate;
>  
>      if (drv->media_inserted) {

Reply via email to