Now that the FSF has received my copyright assignment paper back, I'd like to
become productive on this issue again. From what we've discussed so far I assume
that you prefer
- the introduction of a new command line option
- passing two parameters to probe(), a path and a device, of which one is
Robert Millan schrieb:
I mean that it should find the disk that contains /dev/hda1 device _node_.
Maybe, but I do not believe this has anything to do with my patch.
Is the same output supposed to be printed in all "???" ? If not, what is in
each one?
In all of these cases the 'if (S_ISBLK
On Thu, Feb 14, 2008 at 09:33:48AM +0100, Fabian Greffrath wrote:
> Robert Millan schrieb:
> >The last one sounds like a bug.
>
> Yes, it's from the current *unpatched* grub-probe.
I mean that it should find the disk that contains /dev/hda1 device _node_.
> >Which interface is easier to figure o
Robert Millan schrieb:
The last one sounds like a bug.
Yes, it's from the current *unpatched* grub-probe.
Yes, but does the user know that?
We could tell the user via 'grub-probe --help' that he may pass either a path or
a block device as an argument.
Which interface is easier to figure
On Wed, Feb 13, 2008 at 05:51:53PM +0100, Fabian Greffrath wrote:
> Robert Millan schrieb:
> >I find that too unreliable. How do you reproduce current behaviour with
> >the command "grub-probe -t fs /dev/sda1" ?
>
> I don't see the problem. Why should this be unreliable?
>
> If the device does n
Robert Millan schrieb:
I find that too unreliable. How do you reproduce current behaviour with
the command "grub-probe -t fs /dev/sda1" ?
I don't see the problem. Why should this be unreliable?
If the device does not exist, grub-probe will throw a "cannot stat /dev/sda1"
error with and witho
On Tue, Feb 12, 2008 at 02:17:11PM +0100, Fabian Greffrath wrote:
> Please have a look at the patch I provided in my last mail, too. This is a
> different approach which requires no further command line option but
> *detects* whether the given argument is a path or a device.
I find that too unre
Fabian Greffrath schrieb:
Please have a look at the patch I provided in my last mail, too. This is
a different approach which requires no further command line option but
*detects* whether the given argument is a path or a device.
Ping! ;-)
___
Grub
Please have a look at the patch I provided in my last mail, too. This is a
different approach which requires no further command line option but *detects*
whether the given argument is a path or a device.
___
Grub-devel mailing list
Grub-devel@gnu.org
On Tue, Feb 12, 2008 at 10:49:37AM +0100, Fabian Greffrath wrote:
> >You put that function in a separate file, which indicates it is meant to be
> >a general-purpose function, but its spec is constrained by the code in
> >grub-probe (i.e. you strdup() not because it is needed for the purpose of
> >
You put that function in a separate file, which indicates it is meant to be
a general-purpose function, but its spec is constrained by the code in
grub-probe (i.e. you strdup() not because it is needed for the purpose of
this function, but because grub-probe already calls free()).
That's right.
On Mon, Feb 11, 2008 at 04:48:26PM +0100, Fabian Greffrath wrote:
> >Is there really a need to strdup() it?
>
> Yep. If you return the pointer (i.e. to `path') you'll get memory
> corruption as soon as you try to free (device_name).
You put that function in a separate file, which indicates it is
Hi Robert,
You need to list every function or variable separately. [...]
If you use the -p option to diff it'll be easier to check it just by reading the
patch.
OK, thanks, I didn't know this. Next time... ;)
Is there really a need to strdup() it?
Yep. If you return the pointer (i.e. to `
On Mon, Feb 11, 2008 at 09:53:15AM +0100, Fabian Greffrath wrote:
> The following patch adds to grub-probe the ability to accept system devices
> as
> arguments and e.g. convert between system devices and GRUB drives.
>
> This patch is improved over the one from my previous posting and has some
14 matches
Mail list logo
