On Mon, May 20, 2019 at 06:13:44PM +0200, Christoph Hellwig wrote: > The xfs_buf structure is basically used as a glorified container for > a vmalloc allocation in the log recovery code. Replace it with a > real vmalloc implementation and just build bios directly as needed > to read into or write from it to simplify things a bit. > > Signed-off-by: Christoph Hellwig <hch@xxxxxx> I like the way the series runs in general, and the end result is a fair bit neater, but I'm struggling to work out how we translate this to the userspace code that uses uncached/raw buffer IO. i.e. I'm in the process of porting the xfs_buf.c code to userspace, and was using the uncached buffer API to provide the bits the log code and other raw IO users (xfs_db, repair prefetch) with this functionality through the API this patchset removes. I wrote the patches a couple of days ago to move all this uncached IO and kernel memory and device specific stuff to a xfs_buftarg.[ch] files. This leaves xfs_buf.c as purely cached buffer management code, has no bio stuff in it, no memory allocation, no shrinkers, LRUs, etc). So while it's easy to drop the uncached buffer API from the kernel side, it leaves me with the question of what API do we use in userspace to provide this same functionality? I suspect that we probably need to separate all this log-to-bio code out into a separate file (e.g. xfs_log_io.[ch]) to leave a set of API stubs that we can reimplement in userspace to pread/pwrite directly to the log buftarg device fd as I've done already for the buffer code... Thoughts? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
