From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MHlwD-0002CI-Ag for mharc-grub-devel@gnu.org; Fri, 19 Jun 2009 17:47:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MHlwB-0002Ap-Kj for grub-devel@gnu.org; Fri, 19 Jun 2009 17:47:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MHlw6-00026Y-P0 for grub-devel@gnu.org; Fri, 19 Jun 2009 17:47:54 -0400 Received: from [199.232.76.173] (port=52640 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHlw6-00026T-H3 for grub-devel@gnu.org; Fri, 19 Jun 2009 17:47:50 -0400 Received: from c60.cesmail.net ([216.154.195.49]:8042) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1MHlw5-0008P9-VD for grub-devel@gnu.org; Fri, 19 Jun 2009 17:47:50 -0400 Received: from unknown (HELO smtprelay2.cesmail.net) ([192.168.1.112]) by c60.cesmail.net with ESMTP; 19 Jun 2009 17:47:48 -0400 Received: from [192.168.0.22] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by smtprelay2.cesmail.net (Postfix) with ESMTPSA id 4A8F734C6A for ; Fri, 19 Jun 2009 17:53:32 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: References: <1245424852.3431.30.camel@mj> <1245430369.28417.46.camel@mj> Content-Type: text/plain Date: Fri, 19 Jun 2009 17:47:46 -0400 Message-Id: <1245448066.672.19.camel@mj> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 (2.26.2-1.fc11) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] fix SigSegV and hang with grub-emu-usb 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: Fri, 19 Jun 2009 21:47:56 -0000 On Fri, 2009-06-19 at 20:44 +0200, Vladimir 'phcoder' Serbinenko wrote: > I see the standard is grub_error(). Let's do it for SCSI as > well. > > I don't understand what do you mean. grub_error () which don't come > from previous function You fixed some code in one place, but it's present in more than one place in the same function. Please either do it consistently or explain why it's needed only in one place. Also, I see that .open functions in files under /disk use grub_error() to communicate errors to the caller. Please explain why you want to do it differently in scsi.c. It's possible that the reasons are simple for somebody who reads the code carefully, but if you are submitting the patch, it's important that you demonstrate that you know what you are doing. > Something is wrong with the logic in that function. retrycnt > is only > changed in one place, and if it hits zero, we don't go to the > retry > label. I think the condition can be removed. I don't see how > your > change could have fixed anything in the behavior. > > Wel it didn't fixed the logic completely just one case when it was > wrong. Sorry that patch was low-quality. My goal was to enable > everything by default and the bugs in long-unmaintained libusb code > weren't something I wanted to spend time on. The whole point in enabling more code is to catch such bugs and fix them. Fixing just the immediate obstacles makes the whole task pointless, as it hides half or the problems. Admittedly, I choked a warning in the escape sequence processing in serial.c without fixing the escape sequence support, but the fix would require a major rewrite, and I actually posted a message about the problem. > It seems it's unnecessary. I removed them and it didn't generate any > warnings. Now I followed your recommendation and they build system > with my previous fixes picked it right Good. -- Regards, Pavel Roskin