rq_for_each_bio

rq_for_each_bio

[Adrian McMenamin]

I have tried to search through the mailing list and it is not entirely
clear, but it looks like this has gone from the kernel: not least
because my driver reports:

drivers/sh/gdrom/gdrom.c:665: error: implicit declaration of function
'rq_for_each_bio'

I am not arguing for a stable ABI/API, I get that one - but is there a
canonical source of changes in the kernel (because unless you cross
reference lkml and git repos the mailing list isn't) and if there is -
how can we get it on the first page of google? :)

(Actually, forget the theologocal discussion, tell me about rq_for_each_bio)

Re: rq_for_each_bio

[Neil Brown]

On Sunday December 9, lkmladrian@gmail.com wrote:
> I have tried to search through the mailing list and it is not entirely
> clear, but it looks like this has gone from the kernel: not least
> because my driver reports:
> 
> drivers/sh/gdrom/gdrom.c:665: error: implicit declaration of function
> 'rq_for_each_bio'
> 
> I am not arguing for a stable ABI/API, I get that one - but is there a
> canonical source of changes in the kernel (because unless you cross
> reference lkml and git repos the mailing list isn't) and if there is -
> how can we get it on the first page of google? :)

The canonical source for changes in the kernel is the git history.  It
stores all of them!

The canonical source for changes in the kernel that are important to
your driver is the output of the compiler.  If the compiler triggers
and error where previously it didn't, then you depend on a part of the
kernel that has changed --- if someone makes an API change that does
not cause a compiler error for people who depend on the old
behaviour, then they have done the wrong thing, but that happens
rarely.

If you get a compiler error, you then look in the git history to find
out when the API changed, and read the comment.  in this case it is
commit 5705f7021748a69d84d6567e68e8851dab551464

If you look at this commit, you will see a brief explanation of the
change, and examples of how new code replaced the old.

> 
> (Actually, forget the theologocal discussion, tell me about rq_for_each_bio)

Every instance in the kernel of rq_for_each_bio used the bio simply to
call bio_for_each_segment.  So we discarded rq_for_each_bio and
introduced rq_for_each_segment.  It make code cleaner (less indent
depth) and means that we can make changes to the rules for iterating
through segments in a request in just one central place.  i.e. we have
a higher level of abstraction.

If you have a usage of rq_for_each_bio where rq_for_each_segment
cannot be used, please show us.

NeilBrown