On Thu, Sep 13, 2012 at 03:15:40PM +0400, Dmitry Monakhov wrote: > Current buffer.c API layering looks sub-optimal > > ->xxx_fs_routine: May create different contexts > ->generic_buffer_methods(inode, bh..) > ->xxx_fs_get_block(inode, bh,...): There is no efficient way to pass fscontext > Both xxx_fs_routine and xxx_fs_get_block are fs specific, but > the only way to pass fscontext down to get_block is to pass it by > attaching it to inode, which make it implicit serialization point. > > I just want to add fsprivate argument to get_block_t callback similar > write_begin/write_end and iocb->private, so filesystem will able to pass > it to it's get_block callback. If we're going to change the function prototype for get_block_t, it might also be good to fix a long-standing ugliness with this interface which is that the get_block() interface does two very different things when bh->b_size is greater a single block. If b_size is a greater a block, then instead of bh being a "real" buffer_head, it's a pseudo map_bh. This is annoying because map_bh is generally allocated on the stack, but most of the fields are unused, since it's not really a _real_ buffer_head, but just a countainer for a handful of fields used by the AIO/DIO and mpage.c functions. Instead of changing get_block(), which would require lots of changes all over the kernel, what I'd suggest doing instead is creating a new function which I'd propose calling get_map() which fills in a new structure which replaces map_bh, and which includes the aio_dio structure. It could be made mandatory for the few file systems which support DIO, but that way we don't havec to change the dozens of other file systems which don't use the DIO code paths. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
