[PATCH 00/13] staging: unisys: Remove POSTCODE macros

[Sell, Timothy C]

> -----Original Message-----
> From: Greg KH [mailto:gregkh at linuxfoundation.org]
> Sent: Thursday, December 01, 2016 2:34 AM
> To: Kershner, David A <David.Kershner at unisys.com>
> Cc: driverdev-devel at linuxdriverproject.org; *S-Par-Maintainer
> <SParMaintainer at unisys.com>; jes.sorensen at redhat.com
> Subject: Re: [PATCH 00/13] staging: unisys: Remove POSTCODE macros
> 
> On Thu, Dec 01, 2016 at 01:31:02AM -0500, David Kershner wrote:
> > The s-Par firmware uses POSTCODE macros to get basic health of the
> > system even when we are not connected to the serial port or have
> > the ability to obtain the syslog.
> 
> If you don't have access to a serial port, or a syslog, how can you get
> this data as well?
> 

On an s-Par platform, the Linux environment where the POSTCODEs
are issued is just one virtual guest environment of possibly many hosted by
the s-Par ultravisor (back-end).  POSTCODE data (from ALL guest environments)
ends up in a consolidated log maintained by our ultravisor.  When our
customers supply diagnostics to us for ultravisor problems, they supply to us
what is known as an ldump, which contains this consolidated log file as well
as other diagnostic information.  Oftentimes we don't get guest log files,
and because virtual serial ports require some non-trivial setup ahead-of-time,
we rarely get serial port outputs.

POSTCODE data in our consolidated log file helps provide the "whole picture"
in terms of what is going on in s-Par, because the log includes events
produced by the back-end ultravisor as well as events produced in various
guest environments.  It's also basically the only diagnostic data we can
always count on for a customer to supply when a problem occurs.

- Tim Sell

> > This patch series removes the unsightly postcode macros and creates a
> > simple postcode function to log basic functionality of the controlvm
> > channel.
> 
> It's a lot better, but really, this looks like you are implementing
> ftrace all over again.  Driver subsytems should not have "unique"
> logging solutions, you should use what the kernel provides you and go
> with that.
> 
> If the in-kernel solution doesn't work well for you, then work to change
> that so that the whole kernel benifits (hint, no one usually cares about
> just the logging messages from your tiny drivers, they want to know what
> happened in the overall system.)
> 
> I'll queue up everything but the last patch here, as __LINE__ should
> never be used in a .c file if at all possible (and hint, it usually
> doesn't help you at all as kernel line numbers change all the time
> depending on what distro/version/whatever you are using.)  Worse case,
> put it in a macro, but seriously, it shouldn't be needed at all, you
> should know what is going on by the context of the message itself.
> 
> And finally, you might want to look into the pstore interface if you
> want to write this type of data to something "permanent", but again, the
> default kernel logging system already does this for you, so really, you
> shouldn't have to worry about that either.
> 
> thanks,
> 
> greg k-h