Hi Christoph, On Mon, Sep 02, 2019 at 08:23:23AM -0700, Christoph Hellwig wrote: > On Mon, Sep 02, 2019 at 10:24:52PM +0800, Gao Xiang wrote: > > > code quality stuff. We're not addressing the issues with large amounts > > > of functionality duplicating VFS helpers. > > > > You means killing erofs_get_meta_page or avoid erofs_read_raw_page? > > > > - For killing erofs_get_meta_page, here is the current erofs_get_meta_page: > > > I think it is simple enough. read_cache_page need write a similar > > filler, or read_cache_page_gfp will call .readpage, and then > > introduce buffer_heads, that is what I'd like to avoid now (no need these > > bd_inode buffer_heads in memory...) > > If using read_cache_page_gfp and ->readpage works, please do. The > fact that the block device inode uses buffer heads is an implementation > detail that might not last very long and should be invisible to you. > It also means you can get rid of a lot of code that you don't have > to maintain and others don't have to update for global API changes. I care about those useless buffer_heads in memory for our products... Since we are nobh filesystem (a little request, could I use it after buffer_heads are fully avoided, I have no idea why I need those buffer_heads in memory.... But I think bd_inode is good for caching metadata...) > > > - For erofs_read_raw_page, it can be avoided after iomap tail-end packing > > feature is done... If we remove it now, it will make EROFS broken. > > It is no urgent and Chao will focus on iomap tail-end packing feature. > > Ok. I wish we would have just sorted this out beforehand, which we > could have trivially done without all that staging mess. Firstly, I'd like to introduce EROFS as a self-contained filesystem to introduce new fixed-sized output compression to upstream and promote it... And then we can do many improvements for EROFS in parallel... (if we introduce EROFS and touch many core modules like iomap, mm readahead code or modify LZ4 code at once... It could be more careful... Let's improve it step-by-step... We are a dedicated team if the Linux community needs us, we will still here... It will be actively maintained.) Thanks, Gao Xiang _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
