Hi,
it has become quite obvious that there are different views about how much output flashrom should provide at default verbosity. I'd like to keep line count down, but at the same time I acknowledge that long-running operations need some user feedback. Those goals are not easily reconcilable and there will be some friction. Others would like to upgrade the message levels of quite a few messages and introduce a separate quiet mode which is less verbose than default mode.
Given that this dicussion revolves around the UI and different people expect different things, I don't want to "solve" this by decree. Instead, I hope for consensus.
We definitely need to reach a decision, but maybe we can do this with the help of use cases and by examining typical flashrom output. I'm sure there is some low-hanging fruit where the message content/level can be adjusted and where people agree on the changes.
Regards, Carl-Daniel
On Fri, 22 Jul 2011 01:42:56 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi,
it has become quite obvious that there are different views about how much output flashrom should provide at default verbosity. I'd like to keep line count down, but at the same time I acknowledge that long-running operations need some user feedback. Those goals are not easily reconcilable and there will be some friction. Others would like to upgrade the message levels of quite a few messages and introduce a separate quiet mode which is less verbose than default mode.
Given that this dicussion revolves around the UI and different people expect different things, I don't want to "solve" this by decree. Instead, I hope for consensus.
i think you have read enough already from me regarding this :) so i try to not bore you even more in this message, but ill state a few generic rules for what i think is good default/minimum verbosity (also in the hope we get some company in this discussion, who should be aware of my stance).
the user should be informed about the main steps the program takes.
the user should be informed about any step that potentially takes longer than a few hundred milliseconds (upper bound for this minimum is about 2 seconds. anything longer should be announced in any case).
in the latter case there should be a starting message that explains what will happen with an appended ellipses and a finishing message that makes clear that the waiting time is over.
the user should be informed about any (permanent and transient) errors and its (potential) consequences (this includes "untested stuff" messages). depending on the complexity of the error, enough info to report the cause to the developers should be printed too (i dont mean mail addresses etc, but debugging content like which erase function has failed vs. "an" erase function has failed or pci ids). consequences are of course a hard topic with respect to verbosity, so this needs discussion and trade-offs in each case.
in probing there should be output about programmer(s)/board + chipset (and enables) and chips detected in a level the typical user understands. in other operating modes this is not really necessary (but in case of errors like chip not found).
We definitely need to reach a decision, but maybe we can do this with the help of use cases and by examining typical flashrom output.
i think we need to reach some decisions about some rules similar to the ones above. there is of course place for interpretation, but it would be very useful to have a common bag of rules that we think should be obeyed in general. each output can then be argued based on this rules which i think is easier and quicker than finding those rules by arguing all outputs independently :) they should also be written up on the developer guidelines page when we are done.
I'm sure
there is some low-hanging fruit where the message content/level can be adjusted and where people agree on the changes.
based on "my" rules above i can spot a few things like the header for example. no normal user needs to know the version or building environment at every program run. the "foss" banner could also be dropped". there is another line break in print_banner. so this would free 3 lines on all systems out there. instead of printing it every time there could be a --version parameter which would print those (alone). in more verbose modes the current behavior could be maintained.
that's just one example. if you disagree here.. np, let's focus on getting the rules "right" first.
sorry it got longer than i have hoped (again :)
in the first step carldani wants to introduce a verbosity level between debug and spew. the attached patch adds such a thing.
i argued that using a consistent naming scheme that indicates verbosity with a number after the printing type instead of "info", "err", "dbg", "spew" etc. would be better. for example msg_p2 (programmer messages at verbosity level 2) or msg_g3 (general messages at verbosity level 3). this was vetoed (for now at least ;).
instead of the multiple -V parameters we could add a number after the first V (e.g. -V2 for verbosity level 2). this way we could also include a silent mode more easily without a new character for the parameter. there are no concrete plans for this though (afaik :). my plan was to use the same numbers here and in the code to indicate the level and to make -V0 the silent mode where only errors are reported (or even nothing, and -V1 the error only mode..).
later the library code should support different verbosity levels for different types (e.g. verbosity 1 for generic messages, but verbosity 3 for programmer messages). this does not need to be instantly available for cli users though.
i probably forgot some things that have been discussed (and that's a reason why i wrote the above so that at least that's not lost somewhere in my head :).
we would like to hear any input of other devs regarding this of course!
Hi,
in the first step carldani wants to introduce a verbosity level between debug and spew. the attached patch adds such a thing.
Do we need three versions of debug2? :)
Thanks, Tadas
On Tue, 02 Aug 2011 01:15:24 +0300 Tadas Slotkus devtadas@gmail.com wrote:
Hi,
in the first step carldani wants to introduce a verbosity level between debug and spew. the attached patch adds such a thing.
Do we need three versions of debug2? :)
if you look closely you will see that the 3 macros are not equal. we differentiate between generic, programmer and chip messages, hence the 3 versions.
the question if this is "really needed" should be answered by someone else... :)
Am 01.08.2011 23:52 schrieb Stefan Tauner:
in the first step carldani wants to introduce a verbosity level between debug and spew. the attached patch adds such a thing.
Thanks!
i argued that using a consistent naming scheme that indicates verbosity with a number after the printing type instead of "info", "err", "dbg", "spew" etc. would be better. for example msg_p2 (programmer messages at verbosity level 2) or msg_g3 (general messages at verbosity level 3). this was vetoed (for now at least ;).
I vetoed it for two main reasons: - Named message levels convey a meaning which should make it clear to developers if a message has the right level. - Named message levels are present in the Linux kernel and coreboot.
instead of the multiple -V parameters we could add a number after the first V (e.g. -V2 for verbosity level 2). this way we could also include a silent mode more easily without a new character for the parameter. there are no concrete plans for this though (afaik :). my plan was to use the same numbers here and in the code to indicate the level and to make -V0 the silent mode where only errors are reported (or even nothing, and -V1 the error only mode..).
That would disallow command lines lke the one below: # flashrom -Vw foo.bin Messing with optarg stuff can be fun, but I'm not sure the pain is worth it. That said, the idea in general seems to be good, I just don't see a clean way to implement it.
later the library code should support different verbosity levels for different types (e.g. verbosity 1 for generic messages, but verbosity 3 for programmer messages). this does not need to be instantly available for cli users though.
Changing the msg_* macros to provide print() with a new type parameter which can be ignored by cli_output.c would allow other frontends to implement that functionality as needed.
i probably forgot some things that have been discussed (and that's a reason why i wrote the above so that at least that's not lost somewhere in my head :).
we would like to hear any input of other devs regarding this of course!
I like that patch.
Subject: [PATCH] introduce msg_*dbg2
Signed-off-by: Stefan Tauner stefan.tauner@student.tuwien.ac.at
If it compiles, it is Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Regards, Carl-Daniel
Am 02.08.2011 01:55 schrieb Carl-Daniel Hailfinger:
If it compiles, it is Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Side note: Could you extend the man page as well?
Regards, Carl-Daniel
On Tue, 02 Aug 2011 08:29:25 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 02.08.2011 01:55 schrieb Carl-Daniel Hailfinger:
If it compiles, it is Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Side note: Could you extend the man page as well?
done: -(max. 2 times, i.e. -.BR -VV ) +(max. 3 times, i.e. +.BR -VVV )
On Tue, 2 Aug 2011 13:26:05 +0200 Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
On Tue, 02 Aug 2011 08:29:25 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 02.08.2011 01:55 schrieb Carl-Daniel Hailfinger:
If it compiles, it is Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Side note: Could you extend the man page as well?
done: -(max. 2 times, i.e. -.BR -VV ) +(max. 3 times, i.e. +.BR -VVV )
forgot to mention that this was committed in r1404.
-
Carl-Daniel Hailfinger -
Stefan Tauner -
Tadas Slotkus