From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KaW9A-0007W5-Vt for mharc-grub-devel@gnu.org; Tue, 02 Sep 2008 09:42:16 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KaW99-0007VN-5n for grub-devel@gnu.org; Tue, 02 Sep 2008 09:42:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KaW98-0007Ut-GN for grub-devel@gnu.org; Tue, 02 Sep 2008 09:42:14 -0400 Received: from [199.232.76.173] (port=49325 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaW98-0007Un-9w for grub-devel@gnu.org; Tue, 02 Sep 2008 09:42:14 -0400 Received: from aybabtu.com ([69.60.117.155]:43002) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KaW98-0003sB-6T for grub-devel@gnu.org; Tue, 02 Sep 2008 09:42:14 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KaVyy-0006RI-BU for grub-devel@gnu.org; Tue, 02 Sep 2008 15:31:44 +0200 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1KaW7h-00089E-VV for grub-devel@gnu.org; Tue, 02 Sep 2008 15:40:45 +0200 Date: Tue, 2 Sep 2008 15:40:45 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20080902134045.GB31165@thorin> References: <20080830122626.GA5899@thorin> <20080830114118.3zltziz18g0ss8ws-cebfxv@webmail.spamcop.net> <20080831133355.GC2688@thorin> <1220312369.21219.18.camel@dv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1220312369.21219.18.camel@dv> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] fix disk->id abuse X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 13:42:15 -0000 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 : > > > > > > >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."