Re: Use of floppy disks and parallel ATA on amd64

[Jason Thorpe <thorpej%me.com@localhost>]

> On Oct 15, 2024, at 3:11 AM, Christoph Badura <bad%bsd.de@localhost> wrote:
> 
> 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’s 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 = dkwedge_lookup(dev);

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

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

/*      
 * 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)
{               
    .
    .
    .
                        /*
                         * Call minphys to bound the transfer size,
                         * and remember the amount of data to transfer,
                         * for later comparison.
                         */
                        (*min_phys)(bp);
                        todo = bp->b_bufsize = bp->b_bcount;
    .
    .
    .
}

Problems here include:

1. No way to use this from other I/O paths, like file system I/O … 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 “leaf node” and “root node” (platform constraints - hello sun2!).

3. There’s probably more, but I’m still on my first cup of coffee.

-- thorpej