Re: aprint_* used outside autoconfiguration step

[christos%zoulas.com@localhost (Christos Zoulas)]

On Feb 19,  9:39am, buhrow%nfbcal.org@localhost (Brian Buhrow) wrote:
-- Subject: Re: aprint_* used outside autoconfiguration step

| 	Hello.  I'm a little confused by the goal of this change?  If there
| are are errors worth printing messages about, shouldn't the author of the
| error message have a reasonable expectation that their message will get
| printed via the available kernel printing facilities?  I certainly expect
| if I'm writing a kernel module, that if I call a print routine, my message
| should turn up rather than being ignored.

I think that with the current aprint_ framework we run into two issues:

1. There is code that is called both during autoconfiguration and during
   regular operations. For example the network interface initialization
   code; when there is a need to reload firmware for example, most of
   the drivers use aprint_error_dev() so we end up with an:

	autoconfiguration error: Can't load firmware.

   There is also the behavioral side-effect of using printf() vs.
   using aprint*(): That the AB_* flags affect where it goes.
   I think that the right fix is to not call aprint*() for those
   errors, since they can also happen during regular operations.
   The question still remains though, how does one know that some
   routine is only called during autoconfiguration and they should
   use aprint*() vs. regular operation/both and they should use printf()?
   It is hard to code review and get it right.

2. The aprint*() family has many useful variants, which are missing from
   the regular print*(). like:

       aprint_{normal,verbose,naive,debug}{,_dev,_ifnet}()

   so people end up using those outside the autoconfiguration
   process, because they are convenient (and some people don't
   understand what the "a" in the name stands for). I am not sure
   if we should grow another parallel set of functions...  Perhaps
   it is simpler to just unify them all and have a single set of
   functions. It is not clear to me either, if encoding the level in
   the function name is desirable as opposed to having a separate level
   argument for it (like we traditionally had in the past).

christos