[snip]
>> As I look at this more and more I think trying to re-encode the
>> control flow of the bootm command in a script is just insane.
>> There are too many special cases we have to deal with that we'd
>> just being moving from C code into the script.
>
> My assumption is that a given b
Kumar Gala wrote:
>
> On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
>
>> Kumar Gala wrote:
>>> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
[snip]
What do you think?
>>> While this is a cleaner implementation of what I've implemented w/
>>> ft_env_setup() it still doesn't complet
On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
>
> [snip]
>
>>> One idea that has been spinning in my mind for some time is to
>>> make
>>> the "run" command to execute the content of an environment
>>> variable
>
On Aug 5, 2008, at 9:45 AM, Wolfgang Denk wrote:
> In message
> <[EMAIL PROTECTED]> you wrote:
>> Can we drop any functionality from the current bootm?
>
> Any? You mean:
>
> int bootm (...)
> {
> return 0;
> }
>
> :-)
if it were only so easy :)
>> For example
In message <[EMAIL PROTECTED]> you wrote:
> Can we drop any functionality from the current bootm?
Any? You mean:
int bootm (...)
{
return 0;
}
:-)
> For example does powerpc still need to support bd_t based booting?
Yes, of course we need this. There is
Can we drop any functionality from the current bootm?
For example does powerpc still need to support bd_t based booting?
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Li
In message <[EMAIL PROTECTED]> you wrote:
>
> Yes, that is Wolfgang's (and my) proposal: rationalize the built-in
> "bootm" to do just #6. Steps 1-5 already exist as built-in commands or
> commands could be created almost trivially to invoke the existing code.
> The current "bootm" behavior
Hi,
> Wolfgang Denk wrote:
>>> One minor flaw, I don't see how "bootm" the env script could run "bootm"
>>> the built-in command, because it would instead recursively run "bootm"
>>> the env script if scripts have higher priority and the command line
>>> "bootm" would run the built-in "bootm" i
On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
>
> [snip]
>
>>> One idea that has been spinning in my mind for some time is to
>>> make
>>> the "run" command to execute the content of an environment
>>> variable
>
Wolfgang Denk a écrit :
> In message <[EMAIL PROTECTED]> you wrote:
>>> That's why I think we should have an explicit "builtin" command, i. e.
>>> command with the name "builtin" that will always run the corresponding
>>> builtin command, no if there is a "command alias" or not - similar to
>>> the
Kumar Gala wrote:
> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
[snip]
>> One idea that has been spinning in my mind for some time is to make
>> the "run" command to execute the content of an environment variable
>> optional. Instead, we could try and handle environment variable names
>>
In message <[EMAIL PROTECTED]> you wrote:
>
> > That's why I think we should have an explicit "builtin" command, i. e.
> > command with the name "builtin" that will always run the corresponding
> > builtin command, no if there is a "command alias" or not - similar to
> > the bash command
>
> ...
On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> My current best thought is to create a new "boot simple" (boots?
>> bootsm?) command that contains only the essence of bootm. I would
>> then
>> change the command "bootm" to do a hush script run
Wolfgang Denk wrote:
>> One minor flaw, I don't see how "bootm" the env script could run "bootm"
>> the built-in command, because it would instead recursively run "bootm"
>> the env script if scripts have higher priority and the command line
>> "bootm" would run the built-in "bootm" if scripts h
Wolfgang Denk a écrit :
> That's why I think we should have an explicit "builtin" command, i. e.
> command with the name "builtin" that will always run the corresponding
> builtin command, no if there is a "command alias" or not - similar to
> the bash command
... and make sure that one can *neve
In message <[EMAIL PROTECTED]> you wrote:
>
> That would be REALLY cool! It would take some initial work, but the
> reward would be really simple and transparent expandability for the
> command set. As with the "bootm" command, we might end up with simpler
> code (I don't think too many comman
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> My current best thought is to create a new "boot simple" (boots?
>> bootsm?) command that contains only the essence of bootm. I would then
>> change the command "bootm" to do a hush script run of the env variable
>> "bootm" (i.
In message <[EMAIL PROTECTED]> you wrote:
>
> My current best thought is to create a new "boot simple" (boots?
> bootsm?) command that contains only the essence of bootm. I would then
> change the command "bootm" to do a hush script run of the env variable
> "bootm" (i.e. the command "bootm" wo
Kumar Gala wrote:
> If we really want to simplify what bootm does than I think we should
> remove ft_board_setup() from lib_ppc/bootm.c and expect any actually
> modification of the device tree to have already occurred.
>
> Is this something we'd really be willing to do?
>
> - k
I don't thin
If we really want to simplify what bootm does than I think we should
remove ft_board_setup() from lib_ppc/bootm.c and expect any actually
modification of the device tree to have already occurred.
Is this something we'd really be willing to do?
- k
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm
20 matches
Mail list logo
