linux-kernel - Re: rq_for_each

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 9 Dec 2007 15:19:56 +1100
From:	Neil Brown <neilb@...e.de>
To:	"Adrian McMenamin" <lkmladrian@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: rq_for_each_bio

On Sunday December 9, lkmladrian@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/