Messages in this thread | | | From | David Woodhouse <> | Subject | Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does | Date | Sun, 03 Feb 2002 11:37:59 +0000 |
| |
axboe@suse.de said: > You can do even more than this -- I dunno what I/O interface these > embedded system generally uses (the mtd stuff?). Provided you provide > a direct make_request_fn entry into these instead of using the queue, > you can basically cut all of ll_rw_blk.c and elevator.c.
We don't even do that - look at jffs2_read_super(). The only reason it even _looks_ like we're using a block device is because it was the easiest way to arrange mounting. We only allow you to mount the 'mtdblock' device, which isn't actually used - all we do is use the minor number to look up the real underlying MTD device. The dependency on _any_ of the block code isn't real - I can fix it as soon as there's an incentive to do so (like CONFIG_BLK_DEV).
> ll_rw_block, submit_bh, and generic_make_request would be all that is left.
Those can go too. Likewise page->buffers.
> That should reclaim quite a lot of space. If there's any interest in > this (has it already been done?), I can help out getting it done.
I had a go once. Long enough ago that it's probably not worth trying to find it again. I'd suggest a boolean like CONFIG_BUFFER_CACHE which does the really intrusive stuff like removing page->buffers, and CONFIG_BLK_DEV which can be modular (if CONFIG_BUFFER_CACHE is on), and which controls compilation of everything in drivers/block/ and fs/block_dev.c
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |