[U-Boot-Users] Re: Revised patch: is_console_quiet(), and user feedback control during a TFTP operation
Wolfgang Denk
wd at denx.de
Mon Oct 20 00:56:21 CEST 2003
Dear Jon,
in message <1066216586.8112.17.camel at smoke.cideas.com> you wrote:
>
> I did some QA on my two latest patches, and found some minors problems
> with the patch generation. I have regenerated these two patches. I
> have verified that each patch by itself applies cleanly and doesn't
> cause code bloat.
>
> I should of done this for the first iteration, but I thought it wasn't
> needed. Sorry :<
>
> The two revised patches are attached.
...
> CVS Comments:
>
> - Adding the CFG_CONSOLE_IS_QUIET option to support runtime changes in
> console output. The is_console_quiet() function is used to
> determine the status of quiet mode. Quiet mode is based on the
> value of the "quiet" environment variable. Non-zero values indicate
> that quiet mode is active.
Please explain why we need yet another environment variable to
control the output of console messages. I know that you are aware of
the "silent" stuff. Why do we need something new like "quiet" now?
I don't like to have 20 different implementations of more or less the
same feature.
Also, please consider the use of "setenv stdout nulldev".
Put on hold with a strong tendency to reject it.
> CHANGELOG:
>
> - Adding a number of options to control the user feedback during a
> TFTP operation:
> CFG_TFTP_BLINK_STATUS_ON_DATA_IN
> CFG_TFTP_BLOCKS_PER_HASH
> CFG_TFTP_HASHES_PER_FLASH
> CFG_TFTP_HASHES_PER_LINE
> CFG_TFTP_PROGESS_QUIET
> CFG_TFTP_TIMEOUT_COUNT
Come on - this is complete overkill, isn't it?
> - Toggle the Status LED on TFTP activity - gives nice visual
> indication of booting / network activity
Conflicts with existing status LED driver, which has a pre-defined
function on many boards.
> - Change Status LED back to blinking on TFTP timeout
Breaks function of status LED driver on many boards.
> - Provide control over the maximum TFTP timeout
Please note that code has been added to enable the TFTP client code
to specify to the server the desired timeout value (see RFC-2349).
This should be used.
Sorry, but this is IMHO creaping featurism that does not add any
value but renders the code unreadable.
Can you please explain why you think I should add this?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
If I had to live my life again, I'd make the same mistakes, only
sooner. -- Tallulah Bankhead
More information about the U-Boot
mailing list