[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a781481a0705301414t4a0c1b2epe5e14b62ec8dc872@mail.gmail.com>
Date: Thu, 31 May 2007 02:44:17 +0530
From: "Satyam Sharma" <satyam.sharma@...il.com>
To: "Pete Zaitcev" <zaitcev@...hat.com>
Cc: "Matthias Kaehlcke" <matthias.kaehlcke@...il.com>, axboe@...nel.dk,
linux-usb-devel@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [PATCH] drivers/block/ub.c: use list_for_each_entry()
Hi Pete,
On 5/31/07, Pete Zaitcev <zaitcev@...hat.com> wrote:
> On Wed, 30 May 2007 10:47:52 +0200, Matthias Kaehlcke <matthias.kaehlcke@...il.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.
A list_for_each() followed by list_entry() ---> list_for_each_entry()
conversion is a pretty harmless (and desirable) conversion, IMO.
In fact list_for_each_entry() itself uses list_entry(..., typeof(*p), ...)
which seems to be a safer way to use list_entry() than specifying
the type explicity/manually in its arguments, no?
Satyam
-
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/
Powered by blists - more mailing lists