grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] memory commands


From: Marco Gerards
Subject: Re: [patch] memory commands
Date: Mon, 02 Jan 2006 18:53:19 +0100
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Hollis Blanchard <address@hidden> writes:

> On Jan 2, 2006, at 11:11 AM, Marco Gerards wrote:
>>
>>> +2005-12-12  Hollis Blanchard  <address@hidden>
>>> +
>>> +   * commands/memdebug.c: New file.
>>
>>> +   * kern/powerpc/misc.c: Likewise.
>>> +   * include/grub/powerpc/misc.h: Likewise.
>>> +   * include/grub/i386/misc.h: Likewise.
>>> +   * include/grub/sparc64/misc.h: Likewise.
>>
>> Why don't you use trap.[ch]?  Calling it misc is a bit too generic I
>> think, and I'm afraid everyone put everything in it.
>
> That was my intention. Our build system makes it too painful to
> introduce (then move and rename and remove) new files, and this didn't
> seem important enough to merit its own header anyways.

It's the current practise already.  The disadvantage of adding things
to misc.c is that everything will go in it and it will become a mess.
Can you please rename these files before committing?

>>> +  grub_register_command ("memset", grub_cmd_memset,
>>> GRUB_COMMAND_FLAG_BOTH,
>>> +                    "memset address (value [len] | trap)",
>>> +                    "Write a 32-bit quantity to memory.", 0);
>>
>> This syntax is a bit unusual, I think (for a GNU program).  Mainly
>> because it has quite some conditional parameters.  How about:
>>
>> memset --value=len
>>
>> or:
>>
>> memset --trap
>
> "memset --address=foo --value=bar --len=baz" and "memset --address=foo
> --value=trap"? Far too much typing for a very simple operation.

Can you come up with something better, but without conditional
arguments?

>> Can you please explain what this command does?  To be honest I don't
>> really understand it immediately from the sourcecode. ;-)
>
> It writes a value into a region of memory.

*G*

How about trap?  I didn't understand that part.  In that case you
write the trap instruction to that address?  Shouldn't you flush the
instruction cache in that case?

Have you considered adding a feature so instead of an address a symbol
name can be used? :-)

--
Marco





reply via email to

[Prev in Thread] Current Thread [Next in Thread]