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 <[EMAIL PROTECTED]>: > > > > > > >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." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
