Re: [PATCH] fix disk->id abuse

[Robert Millan]

On Mon, Sep 01, 2008 at 07:39:29PM -0400, Pavel Roskin wrote:
> On Sun, 2008-08-31 at 15:33 +0200, Robert Millan wrote:
> > On Sat, Aug 30, 2008 at 11:41:18AM -0400, Pavel Roskin wrote:
> > > Quoting Robert Millan <address@hidden>:
> > > 
> > > >So this patch means to solve both issues;  makes single-disk drivers use 
> > > >a
> > > >constant directly (since a pointer to string is meaningless and 
> > > >confusing),
> > > >and disk/scsi.c use LUNs which (I believe) will work as unique 
> > > >identifiers.
> > > 
> > > Multi-character constants cause warnings.
> > 
> > Can we silence them?
> 
> I don't think so.  Besides, strings are just as good as multi-character
> constants.  In fact, strings are better, as they won't clash with any
> pointers, simply because strings are pointers too, and they point to
> areas in memory not used by other drivers.
> 
> > > That's why I changed them  
> > > to strings.  Pointers to different strings are different, and that's  
> > > all we need.
> > 
> > For single-disk drivers, yes.  But that has two problems:
> > 
> >   - People tend to think the string itself has a meaning.  We could avoid
> >     this by using "dummy" or so.
> 
> There is a chance that pointers to "dummy" will be consolidated by the
> linker.  I believe GNU ld won't do it, but it's not impossible.

Ok then.

> >   - People tend to think it's fine to do the same for multi-disk drivers.
> >     We could avoid this by adding a short comment in each of them.
> 
> Maybe we could rename "id" to something more descriptive.  But I don't
> think it's a big concern.  Somebody writing a disk driver will need to
> check the meaning of the disk structure.
> 
> We could write a macro for ID comparison that would compare both the
> "driver ID" (disk->dev->id) and "device ID" (disk->id).  In this case,
> we can omit disk->id initialization in the drivers supporting only one
> device (e.g. memdisk) and only leave it where it's indeed needed for
> identifying separate devices, thus removing potentially confusing code.

Sounds fine, although what worries me most if the current usage of 'id' in
scsi.c, which can lead to collision already.

I assume using LUNs is a proper solution for that one?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."