From: Matthias Kaehlcke <matthias.kaehlcke@gmail.com>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: axboe@kernel.dk, linux-usb-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH] drivers/block/ub.c: use list_for_each_entry()
Date: Wed, 30 May 2007 22:28:00 +0200 [thread overview]
Message-ID: <20070530202800.GL14284@traven> (raw)
In-Reply-To: <20070530123840.e54d73c2.zaitcev@redhat.com>
El Wed, May 30, 2007 at 12:38:40PM -0700 Pete Zaitcev ha dit:
> On Wed, 30 May 2007 10:47:52 +0200, Matthias Kaehlcke <matthias.kaehlcke@gmail.com> wrote:
>
> > @@ -1608,8 +1605,7 @@ static void ub_reset_task(struct work_struct *work)
> > spin_lock_irqsave(sc->lock, flags);
> > sc->reset = 0;
> > tasklet_schedule(&sc->tasklet);
> > - list_for_each(p, &sc->luns) {
> > - lun = list_entry(p, struct ub_lun, link);
> > + list_for_each_entry(lun, &sc->luns, link) {
> > blk_start_queue(lun->disk->queue);
> > }
> > wake_up(&sc->reset_wait);
>
> This patch straddles the border of acceptable. The pointless obfuscation
> is balanced against the removal of explicit type in list_entry() and thus
> a possible mismatched struct. I'm not acking nor naking this.
if i understand you correctly the problem isn't so much the patch, but
the use of list_for_each_entry() in general. i thought
list_for_each_entry() is preferred over list_for_each() when its use
is possible.
i understand your point, though i think only a chain of errors would
make list_for_each_entry() a problem without being notified by the
compiler:
1) the mismatched struct must have a list_head pointer
2) the name of this list_head pointer must match the name in
list_for_each_entry()
3) the mismatched struct must be 'compatible' with the code in the
loop
please correct me if i misinterpreted the reason of your concerns
regards
--
Matthias Kaehlcke
Linux Application Developer
Barcelona
El trabajo es el refugio de los que no tienen nada que hacer
(Oscar Wilde)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
next prev parent reply other threads:[~2007-05-30 20:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-30 8:47 [PATCH] drivers/block/ub.c: use list_for_each_entry() Matthias Kaehlcke
2007-05-30 19:38 ` Pete Zaitcev
2007-05-30 20:28 ` Matthias Kaehlcke [this message]
2007-05-30 21:14 ` Satyam Sharma
2007-05-30 23:08 ` Pete Zaitcev
2007-05-30 23:14 ` Roland Dreier
2007-05-30 23:32 ` Pete Zaitcev
2007-05-30 23:42 ` Roland Dreier
2007-05-31 0:05 ` Pete Zaitcev
2007-05-31 4:28 ` Roland Dreier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070530202800.GL14284@traven \
--to=matthias.kaehlcke@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox