Re: Use of floppy disks and parallel ATA on amd64

> On Oct 15, 2024, at 3:11=E2=80=AFAM, Christoph Badura <[email protected]> =
wrote:
>=20
> What actual technical problems do you want to address this way?
> Preferably ones that we have actually observed in the real world.

The real problem is that MAXPHYS is being used for anything related to =
file system I/O at all.  That, combined with a lack of kernel =
infrastructure for properly publishing (and consuming) I/O attributes =
throughout the device stack.

Drivers already have a way to clamp the maximum I/O size, on a per-I/O =
basis even!  The problem is that it=E2=80=99s only used for physio (i.e. =
when you read from /dev/rsd1c or whatever).

Behold:

static int
dkread(dev_t dev, struct uio *uio, int flags)
{
        struct dkwedge_softc *sc __diagused =3D dkwedge_lookup(dev);

        KASSERT(sc !=3D NULL);
        KASSERT(sc->sc_dev !=3D NULL);
        KASSERT(sc->sc_state !=3D DKW_STATE_LARVAL);
        KASSERT(sc->sc_state !=3D DKW_STATE_DEAD);

        return physio(dkstrategy, NULL, dev, B_READ, dkminphys, uio);
}

/*     =20
 * Do "physical I/O" on behalf of a user.  "Physical I/O" is I/O =
directly
 * from the raw device to user buffers, and bypasses the buffer cache.
 */
int
physio(void (*strategy)(struct buf *), struct buf *obp, dev_t dev, int =
flags,
    void (*min_phys)(struct buf *), struct uio *uio)
{              =20
    .
    .
    .
                        /*
                         * Call minphys to bound the transfer size,
                         * and remember the amount of data to transfer,
                         * for later comparison.
                         */
                        (*min_phys)(bp);
                        todo =3D bp->b_bufsize =3D bp->b_bcount;
    .
    .
    .
}

Problems here include:

1. No way to use this from other I/O paths, like file system I/O =E2=80=A6=
 there are lots of other random limits that get involved there (e.g. =
UBC_WINSIZE), none of which are directly related to the capabilities of =
the underlying device.

2. No way to consider limits further up the chain.  The capabilities of =
the end block device are only just one aspect.  You need to consider =
limits of e.g. an intervening IOMMU, or maybe a buggy revision of a PCI =
bridge.  Right now, we have =E2=80=9Cleaf node=E2=80=9D and =E2=80=9Croot =
node=E2=80=9D (platform constraints - hello sun2!).

3. There=E2=80=99s probably more, but I=E2=80=99m still on my first cup =
of coffee.

-- thorpej