Re: log(9) variant for device error messages

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

On Jun 16,  3:49pm, Quentin Garnier wrote:
} Subject: Re: log(9) variant for device error messages
} 
} When I say "retire", I mostly mean "stop documenting".  As you point you,
} there is little point (beside annoying people) in removing the aprint_*
} API.
} 
} But if it could gently be pushed out to the retirement castle, I wouldn't
} mind the slightest.
} 
        Hello.  Back when I was writing driver code for NetBSD-0.9, we just
used printf() when we wanted to print a message.  Then, at some point, we
switched to using aprint_* functions.  The number of drivers we have now is
far greater than it was with NetBSD-0.9.  What I'm asking is why retire the
API at all.  Why not just change the internals of the aprint_* functions to
accomodate the evolving needs of the kernel and keep the calling API the
same?  Today, some drivers use printf(), some use aprint_*() and others use
log().  I don't see the value in introducing a fourth interface for
printing messages.  I do understand that drivers may want to print messages
when the kernel is running with interrupts enabled, in full multiprocessor
mode, or they may want to print messages when the kernel is still being
initialized and not all subsystems are up and running.  With the possible
exception of printf(), why not just make the  aprint_*() and log()
functions front ends for the same notification subsystem in the kernel?
Perhaps printf() could be  drawn in as well, but I suspect that's actually
harder than doing the other two.  Is there some semantic these existing API's
can't get at with possibly the addition of a flag or two that the proposed
API covers?

-thanks
-Brian