Date: Mon, 6 Oct 2003 16:44:32 -0600 (MDT) From: Scott Long <scottl@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: Alignment of disk-I/O from userland. Message-ID: <20031006163218.L55190@pooker.samsco.home> In-Reply-To: <26369.1065477317@critter.freebsd.dk> References: <26369.1065477317@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 Oct 2003, Poul-Henning Kamp wrote: > In message <200310062146.h96Lkpx0093486@khavrinen.lcs.mit.edu>, Garrett Wollman > writes: > > >I think that gives us plenary authority to require appropriate > >alignment of data buffers used to access disk devices directly. > > Well, apart from us wedging or botching the request rather than > return a consistent error we're standards compliant then. > > It has been mentioned on #thatchannel that busdma should take care > of this by copying the request as necessary. Faced with the prospect > of a request several megabytes in size, I don't like the prospect > of malloc/bcopy too much. Working around hardware requirements from the block layer gets messy. You obviously don't want to manually align buffers that are distined for hardware that doesn't care about the alignment. How do you communicate this property upwards from the driver? Callbacks? Extra flags in disk_create()? It's all rather messy that way. We already have the busdma interface whose sole purpose is to take system buffers and prepare them for transfer to/from hardware. It already understands the concept of alignment, though it only applies it to buffers that it allocates, not buffers that are handed to it. Fixing that would be easy, and would allow for optimizations based on the bus (GART and IOMMU remapping). It also keeps the property down at the device driver where it belongs. As for returning an error code for a buffer that we (arbitrarily) believe to be too big to align, I'm not sure that it's a valid thing to worry about. People expect their hardware to Just Work, regardless of how cheap it is. If someone buys a cheap card with a cheap DMA engine, their cost comes in from higher system time per I/O. If they don't like that, they can complain to the manufacturer and/or buy a better card. I'm not aware of Linux nor OSX rejecting I/O based on arbitrary size limits. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031006163218.L55190>