Re: [flashrom] [PATCH] chipset_enable.c: add a message in the case the chipset enable is untested

[Carl-Daniel Hailfinger]

Am 21.07.2011 14:23 schrieb Stefan Tauner:
> old output:
> Found chipset "Intel QS57", enabling flash write... OK.
> This chipset supports the following protocols: FWH, SPI.
>
> new non-verbose output for tested chipsets:
> Found chipset "Intel QS57". Enabling flash write... OK.
> This chipset supports the following protocols: FWH, SPI.
>
> new non-verbose output for untested chipsets:
> Found chipset "Intel QS57".
> This chipset is marked as untested. If you are using an up-to-date version
> of flashrom please email a report to [e-mail] including a
> verbose (-V) log. Thank you!
> Enabling flash write... OK.
> This chipset supports the following protocols: FWH, SPI.

4 additional lines... sorry, but that's simply too much. We have users
of the DOS version of flashrom, and they have an 80x25 terminal, so
wasting 4 lines (16% of the screen) is not acceptable. 2 more lines are
already 8% of the screen.
The following text would be shorter (2 additional lines), but I'd be
happy to see a patch trimming it down even more to one additional line.

Found chipset "Intel QS57" (untested). Enabling flash write... OK.
If you are using an up-to-date version of flashrom please email a report
to [e-mail] including a verbose (-V) log. Thank you!
This chipset supports the following protocols: FWH, SPI.

Regards,
Carl-Daniel

[PATCH] chipset_enable.c: add a message in the case the chipset enable is untested

[Paul Menzel]

Am Donnerstag, den 21.07.2011, 22:55 +0200 schrieb Carl-Daniel Hailfinger:
> Am 21.07.2011 14:23 schrieb Stefan Tauner:
> > old output:
> > Found chipset "Intel QS57", enabling flash write... OK.
> > This chipset supports the following protocols: FWH, SPI.
> >
> > new non-verbose output for tested chipsets:
> > Found chipset "Intel QS57". Enabling flash write... OK.
> > This chipset supports the following protocols: FWH, SPI.
> >
> > new non-verbose output for untested chipsets:
> > Found chipset "Intel QS57".
> > This chipset is marked as untested. If you are using an up-to-date version
> > of flashrom please email a report to [e-mail] including a
> > verbose (-V) log. Thank you!
> > Enabling flash write... OK.
> > This chipset supports the following protocols: FWH, SPI.
>
> 4 additional lines... sorry, but that's simply too much. We have users
> of the DOS version of flashrom, and they have an 80x25 terminal, so
> wasting 4 lines (16% of the screen) is not acceptable. 2 more lines are
> already 8% of the screen.

Hmm, how many users are using the DOS version? Is there a way to compile
a short message for DOS users and a longer one for other users who can
scroll or have more lines?
> The following text would be shorter (2 additional lines), but I'd be
> happy to see a patch trimming it down even more to one additional line.
>
> Found chipset "Intel QS57" (untested). Enabling flash write... OK.
> If you are using an up-to-date version of flashrom please email a report
> to [e-mail] including a verbose (-V) log. Thank you!
> This chipset supports the following protocols: FWH, SPI.

If you are using an *up-to-date* version of flashrom please send a
report to [e-mail] pasting a verbose (-V) log with the
following subject line. Thank you!
%s %s" + ": verbose output of flashrom version %s" ,
                         chipset_enables[i].vendor_name,
                         chipset_enables[i].device_name,
                         variable_holding_the_version)

This chipset supports the following protocols: FWH, SPI.

Thanks,

Paul

[PATCH] chipset_enable.c: add a message in the case the chipset enable is untested

[Stefan Tauner]

On Thu, 21 Jul 2011 22:55:07 +0200
Carl-Daniel Hailfinger  wrote:
> Am 21.07.2011 14:23 schrieb Stefan Tauner:
> > old output:
> > Found chipset "Intel QS57", enabling flash write... OK.
> > This chipset supports the following protocols: FWH, SPI.
> >
> > new non-verbose output for tested chipsets:
> > Found chipset "Intel QS57". Enabling flash write... OK.
> > This chipset supports the following protocols: FWH, SPI.
> >
> > new non-verbose output for untested chipsets:
> > Found chipset "Intel QS57".
> > This chipset is marked as untested. If you are using an up-to-date version
> > of flashrom please email a report to [e-mail] including a
> > verbose (-V) log. Thank you!
> > Enabling flash write... OK.
> > This chipset supports the following protocols: FWH, SPI.
>
> 4 additional lines... sorry, but that's simply too much. We have users
> of the DOS version of flashrom, and they have an 80x25 terminal, so
> wasting 4 lines (16% of the screen) is not acceptable. 2 more lines are
> already 8% of the screen.

but 9 lines for untested chips is worth it?
> The following text would be shorter (2 additional lines), but I'd be
> happy to see a patch trimming it down even more to one additional line.
>
> Found chipset "Intel QS57" (untested). Enabling flash write... OK.
> If you are using an up-to-date version of flashrom please email a report
> to [e-mail] including a verbose (-V) log. Thank you!
> This chipset supports the following protocols: FWH, SPI.

this one prints the message after enabling write... the computer could
already be on fire at that time if the chipset enable wrecks havoc!

seriously... i thought it is better to call the chipset enable after the
message. and TBH i did not put too much thought into reducing line
count, because my message was already way shorter than the chip message.
till now i was mainly concerned about character/word count in messages
not line count. dos users... well they should get an OS, use redirection
or not get in my way :P

for most users (those with supported chipsets) there is no change at
all. for others this message comes pretty early in the process so the
really important messages are not dropped... i can live with this patch
(and it is already committed).

[PATCH] chipset_enable.c: add a message in the case the chipset enable is untested

[Carl-Daniel Hailfinger]

Am 21.07.2011 23:59 schrieb Stefan Tauner:
> On Thu, 21 Jul 2011 22:55:07 +0200
> Carl-Daniel Hailfinger  wrote:
> > Am 21.07.2011 14:23 schrieb Stefan Tauner:
> > > old output:
> > > Found chipset "Intel QS57", enabling flash write... OK.
> > > This chipset supports the following protocols: FWH, SPI.
> > >
> > > new non-verbose output for tested chipsets:
> > > Found chipset "Intel QS57". Enabling flash write... OK.
> > > This chipset supports the following protocols: FWH, SPI.
> > >
> > > new non-verbose output for untested chipsets:
> > > Found chipset "Intel QS57".
> > > This chipset is marked as untested. If you are using an up-to-date version
> > > of flashrom please email a report to [e-mail] including a
> > > verbose (-V) log. Thank you!
> > > Enabling flash write... OK.
> > > This chipset supports the following protocols: FWH, SPI.
> >
> > 4 additional lines... sorry, but that's simply too much. We have users
> > of the DOS version of flashrom, and they have an 80x25 terminal, so
> > wasting 4 lines (16% of the screen) is not acceptable. 2 more lines are
> > already 8% of the screen.
>
> but 9 lines for untested chips is worth it?

Absolutely not.
You are correct that this is an imbalance which needs to be fixed.
> > The following text would be shorter (2 additional lines), but I'd be
> > happy to see a patch trimming it down even more to one additional line.
> >
> > Found chipset "Intel QS57" (untested). Enabling flash write... OK.
> > If you are using an up-to-date version of flashrom please email a report
> > to [e-mail] including a verbose (-V) log. Thank you!
> > This chipset supports the following protocols: FWH, SPI.
>
> this one prints the message after enabling write... the computer could
> already be on fire at that time if the chipset enable wrecks havoc!

You're right, this is indeed a possible outcome.
We could downgrade "Enabling flash write... OK" and "This chipset
supports the following protocols: foo, bar" to msg_pdbg because that
information is only interesting for debugging anyway. That would also
allow us to keep the current (svn HEAD) message order and avoid the
corner case you found.
> seriously... i thought it is better to call the chipset enable after the
> message. and TBH i did not put too much thought into reducing line
> count, because my message was already way shorter than the chip message.
> till now i was mainly concerned about character/word count in messages
> not line count. dos users... well they should get an OS, use redirection
> or not get in my way :P

You'd be surprised how many of our users use DOS, usually because they
don't know Linux.
> for most users (those with supported chipsets) there is no change at
> all. for others this message comes pretty early in the process so the
> really important messages are not dropped... i can live with this patch
> (and it is already committed).

Regards,
Carl-Daniel

[PATCH] chipset_enable.c: add a message in the case the chipset enable is untested

[Stefan Tauner]

On Fri, 22 Jul 2011 00:27:49 +0200
Carl-Daniel Hailfinger  wrote:
> Am 21.07.2011 23:59 schrieb Stefan Tauner:
> > On Thu, 21 Jul 2011 22:55:07 +0200
> > Carl-Daniel Hailfinger  wrote:
> > > Am 21.07.2011 14:23 schrieb Stefan Tauner:
> > >
> > > The following text would be shorter (2 additional lines), but I'd be
> > > happy to see a patch trimming it down even more to one additional line.
> > >
> > > Found chipset "Intel QS57" (untested). Enabling flash write... OK.
> > > If you are using an up-to-date version of flashrom please email a report
> > > to [e-mail] including a verbose (-V) log. Thank you!
> > > This chipset supports the following protocols: FWH, SPI.
> >
> > this one prints the message after enabling write... the computer could
> > already be on fire at that time if the chipset enable wrecks havoc!
>
> You're right, this is indeed a possible outcome.
> We could downgrade "Enabling flash write... OK" and "This chipset
> supports the following protocols: foo, bar" to msg_pdbg because that
> information is only interesting for debugging anyway. That would also
> allow us to keep the current (svn HEAD) message order and avoid the
> corner case you found.

good idea imo.
> > seriously... i thought it is better to call the chipset enable after the
> > message. and TBH i did not put too much thought into reducing line
> > count, because my message was already way shorter than the chip message.
> > till now i was mainly concerned about character/word count in messages
> > not line count. dos users... well they should get an OS, use redirection
> > or not get in my way :P
>
> You'd be surprised how many of our users use DOS, usually because they
> don't know Linux.

not at all. i am aware of that, but that is not my problem but theirs :)
i would even argue that flashrom is a good opportunity for them to get
familiar with unices in the form of livecds, but that is of course not
my decision to make (not until i am leader of the world, that is :)

what i basically tried to say is, that i am glad flashrom is able to
run in dos (more or less), but jumping through too many hoops is not an
option (for me). i will try to factor in their line limit and inability
to scroll (is that still correct for freedos?) in future patches though.

[PATCH] chipset_enable.c: add a message in the case the chipset enable is untested

[Uwe Hermann]

On Fri, Jul 22, 2011 at 10:05:10AM +0200, Stefan Tauner wrote:
> > > seriously... i thought it is better to call the chipset enable after the
> > > message. and TBH i did not put too much thought into reducing line
> > > count, because my message was already way shorter than the chip message.
> > > till now i was mainly concerned about character/word count in messages
> > > not line count. dos users... well they should get an OS, use redirection
> > > or not get in my way :P
> >
> > You'd be surprised how many of our users use DOS, usually because they
> > don't know Linux.

Just a side-note, this is not really about DOS, I use 80x25 xterms on
Linux all the time. But I have no problem with one or two lines more or
less in the output, either way.

DOS users have a problem with -V output already I assume, whatever they
do to handle that can probably also be applied to the case without -V.
> option (for me). i will try to factor in their line limit and inability
> to scroll (is that still correct for freedos?) in future patches though.

No idea if scrolling is possible or not. I think the best option would
be to have a more finegrained control of the loglevel in flashrom, i.e.
--log-level=0,1,2,3 etc. (instead of "no -V", "-V", and "-VV"), so the
user can also choose 0 or 1 to get only the bare minumum output.

Uwe.

[PATCH] chipset_enable.c: add a message in the case the chipset enable is untested

[Bernd Blaauw]

Op 22-7-2011 12:48, Uwe Hermann schreef:
> DOS users have a problem with -V output already I assume, whatever they
> do to handle that can probably also be applied to the case without -V.

Redirection does the trick, followed by opening the output file in some 
editor. Other options are changing screen resolution temporarily (80x43 
or 80x50), hitting some kind PAUSE (press a key to continue), or on 
error, offer to write a file (generated/kept in memory) to disk with 
full verbosity level on.
> > option (for me). i will try to factor in their line limit and inability
> > to scroll (is that still correct for freedos?) in future patches though.
>
> No idea if scrolling is possible or not. I think the best option would
> be to have a more finegrained control of the loglevel in flashrom, i.e.
> --log-level=0,1,2,3 etc. (instead of "no -V", "-V", and "-VV"), so the
> user can also choose 0 or 1 to get only the bare minumum output.

There should be scrolling applications, just not aware of them. Flashrom 
implementing scrolling abilities just for DOS seems a bit silly.

Redirection in general works, it's only when you're trying to provide 
too much info at default verbosity level that things get tricky as you 
can't scroll back then anymore.

Reason for me for liking Flashrom program on DOS is that it runs in a 
minimal and fast environment, compared to starting Linux LiveCD for 
example. Also requirements are a lot lower, I don't see any Linux 
LiveCDs on low-end Pentium-1 machines due to system memory requirements. 
Or I'm just plain bad at finding non-GUI Linux environments. Drawback is 
lack of internet environment etc for posting logs, downloading BIOS etc.

Best compromise so far seems Parted Magic using your software, it's a 
180MB distribution, so seems doable.