Re: [PATCH 000 of 5] Introductory patches for bio refactor.
On Thu, Aug 16 2007, NeilBrown wrote: > > Hi Jens, > I wonder if you would accept these patches the block layer. > They are, as far as I can tell, quite uncontroversial and provide > good cleanups. > > The first is a minor bug-fix. > The next to replace helper function that take a bio (always the first > bio of a request), to instead take a request. > > The last two combine to replace rq_for_each_bio with > rq_for_each_segment which makes blk_recalc_rq_segments a lot > cleaner, and improves (to a lesser degree) every other place that > used rq_for_each_bio. > > The net result is a decrease in object code size (for my x86-64 compile) > for block/built-in.o of 96 bytes, though there is some growth out in > drivers making and over-all decrease of only 48 bytes. Thanks for seperating these out Neil, will go over them this morning! -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 000 of 5] Introductory patches for bio refactor.
On Thu, Aug 16 2007, NeilBrown wrote: Hi Jens, I wonder if you would accept these patches the block layer. They are, as far as I can tell, quite uncontroversial and provide good cleanups. The first is a minor bug-fix. The next to replace helper function that take a bio (always the first bio of a request), to instead take a request. The last two combine to replace rq_for_each_bio with rq_for_each_segment which makes blk_recalc_rq_segments a lot cleaner, and improves (to a lesser degree) every other place that used rq_for_each_bio. The net result is a decrease in object code size (for my x86-64 compile) for block/built-in.o of 96 bytes, though there is some growth out in drivers making and over-all decrease of only 48 bytes. Thanks for seperating these out Neil, will go over them this morning! -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 000 of 5] Introductory patches for bio refactor.
Hi Jens, I wonder if you would accept these patches the block layer. They are, as far as I can tell, quite uncontroversial and provide good cleanups. The first is a minor bug-fix. The next to replace helper function that take a bio (always the first bio of a request), to instead take a request. The last two combine to replace rq_for_each_bio with rq_for_each_segment which makes blk_recalc_rq_segments a lot cleaner, and improves (to a lesser degree) every other place that used rq_for_each_bio. The net result is a decrease in object code size (for my x86-64 compile) for block/built-in.o of 96 bytes, though there is some growth out in drivers making and over-all decrease of only 48 bytes. Thanks, NeilBrown [PATCH 001 of 5] Don't update bi_hw_*_size if we aren't going to merge. [PATCH 002 of 5] Replace bio_data with blk_rq_data [PATCH 003 of 5] Replace bio_cur_sectors with blk_rq_cur_sectors. [PATCH 004 of 5] Introduce rq_for_each_segment replacing rq_for_each_bio [PATCH 005 of 5] Merge blk_recount_segments into blk_recalc_rq_segments - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 000 of 5] Introductory patches for bio refactor.
Hi Jens, I wonder if you would accept these patches the block layer. They are, as far as I can tell, quite uncontroversial and provide good cleanups. The first is a minor bug-fix. The next to replace helper function that take a bio (always the first bio of a request), to instead take a request. The last two combine to replace rq_for_each_bio with rq_for_each_segment which makes blk_recalc_rq_segments a lot cleaner, and improves (to a lesser degree) every other place that used rq_for_each_bio. The net result is a decrease in object code size (for my x86-64 compile) for block/built-in.o of 96 bytes, though there is some growth out in drivers making and over-all decrease of only 48 bytes. Thanks, NeilBrown [PATCH 001 of 5] Don't update bi_hw_*_size if we aren't going to merge. [PATCH 002 of 5] Replace bio_data with blk_rq_data [PATCH 003 of 5] Replace bio_cur_sectors with blk_rq_cur_sectors. [PATCH 004 of 5] Introduce rq_for_each_segment replacing rq_for_each_bio [PATCH 005 of 5] Merge blk_recount_segments into blk_recalc_rq_segments - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
