On Thu, Dec 01, 2016 at 11:37:09AM +0000, Sell, Timothy C wrote: > > -----Original Message----- > > From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > > Sent: Thursday, December 01, 2016 2:34 AM > > To: Kershner, David A <David.Kershner@xxxxxxxxxx> > > Cc: driverdev-devel@xxxxxxxxxxxxxxxxxxxxxx; *S-Par-Maintainer > > <SParMaintainer@xxxxxxxxxx>; jes.sorensen@xxxxxxxxxx > > 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. Ok, but that's only giving you some random data about your specific drivers, not the whole Linux system. Why not use the pdata interface instead to send the logs to your "consolidated log file" so that you now get all of the kernel's information, not just your tiny driver. Again, driver-specific logging methods is not ok. Just look at how many different driver subsystems we have in the kernel, there's a reason people unified all of this many many years ago, let's not go backwards. thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
