Re: [PATCH] drivers/block/ub.c: use list_for_each_entry()

[Matthias Kaehlcke <matthias.kaehlcke@gmail.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                  `-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/