All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] fix SigSegV and hang with grub-emu-usb
Date: Fri, 19 Jun 2009 17:47:46 -0400	[thread overview]
Message-ID: <1245448066.672.19.camel@mj> (raw)
In-Reply-To: <d7ead6de0906191144p4fe95cc3r8b6d8087e71d1740@mail.gmail.com>

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



  parent reply	other threads:[~2009-06-19 21:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-19 14:58 [PATCH] fix SigSegV and hang with grub-emu-usb Vladimir 'phcoder' Serbinenko
2009-06-19 15:20 ` Pavel Roskin
2009-06-19 15:54   ` Vladimir 'phcoder' Serbinenko
2009-06-19 16:52     ` Pavel Roskin
2009-06-19 18:44       ` Vladimir 'phcoder' Serbinenko
2009-06-19 19:14         ` Vladimir 'phcoder' Serbinenko
2009-06-19 21:47         ` Pavel Roskin [this message]
2009-06-19 21:56           ` Vladimir 'phcoder' Serbinenko
2009-07-16 15:36         ` Vladimir 'phcoder' Serbinenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1245448066.672.19.camel@mj \
    --to=proski@gnu.org \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.