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] Re: grub-install --root-directory=/mnt /dev/sda1 fails
Date: Fri, 12 Jun 2009 12:21:54 -0400	[thread overview]
Message-ID: <1244823714.9051.42.camel@mj> (raw)
In-Reply-To: <1244802503.3181.0.camel@fz.local>

On Fri, 2009-06-12 at 12:28 +0200, Felix Zielcke wrote:

> Ok here's a new one which compiles without warnings.

I suggest that whenever a patch is published, it comes with a detailed
description.  Surely, it could be gathered by rereading the thread, but
I think it's not sufficient for two reasons.

The first reason is that we want the patches reviewed by more people.
Not everybody has time to read the whole discussion.

The second reason is that the description the shows how the author sees
the changes, what the potential benefits are, what code is affected.
The reviewers would be able to compare the goals to the implementation.

Even if the description was already published, it should not be hard to
publish it again, perhaps with some improvements.

Regarding this patch, I don't think we need to add a function to
hostdisk.c is it's only used in grub-setup.c.  It would be better to
have it in grub-setup.c unless it's a generic function or there is a
good chance that it will be used elsewhere.

grub_make_system_path_relative_to_its_root is a very long name.  There
is nothing wrong with a long name per se, but it may be in sign that the
function is too specialized and should not be in hostdisk.c.

Following is not good for several reasons:

#warning "The function `grub_make_system_path_relative_to_its_root'
might not work on your OS correctly."

The warning will only be seen by those who compile GRUB, but not by the
end users who installed a binary.  The warning doesn't explain what
exactly may not work correctly.  Since we are talking about new
functionality here, I'd rather omit an unsafe implementation if
realpath() is not available.

What is free_ptr?  It looks like it's a pointer that the caller should
free.  I think functions should be self-contained and should not ask the
caller to do the cleanup (unless they actually return something useful
in the allocated memory).

-- 
Regards,
Pavel Roskin



  reply	other threads:[~2009-06-12 16:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-06 14:31 grub-install --root-directory=/mnt /dev/sda1 fails Felix Zielcke
2009-05-06 15:12 ` Vladimir 'phcoder' Serbinenko
2009-06-01 19:39   ` Felix Zielcke
2009-06-08 21:20     ` [PATCH] " Felix Zielcke
2009-06-09 21:51       ` Vladimir 'phcoder' Serbinenko
2009-06-10 23:00         ` Felix Zielcke
2009-06-11 23:21           ` Felix Zielcke
2009-06-11 23:25             ` Felix Zielcke
2009-06-12 10:28               ` Felix Zielcke
2009-06-12 16:21                 ` Pavel Roskin [this message]
2009-06-12 16:33                   ` Felix Zielcke
2009-07-01 14:33     ` Felix Zielcke
2009-07-04 20:09       ` Robert Millan
2009-07-08 14:16         ` Felix Zielcke

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=1244823714.9051.42.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.