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/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:27 EST