Re: [PATCH 00/13] staging: unisys: Remove POSTCODE macros
On Thu, Dec 01, 2016 at 11:37:09AM +, Sell, Timothy C wrote: > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Thursday, December 01, 2016 2:34 AM > > To: Kershner, David A <david.kersh...@unisys.com> > > Cc: driverdev-devel@linuxdriverproject.org; *S-Par-Maintainer > > <sparmaintai...@unisys.com>; jes.soren...@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. 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 de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 00/13] staging: unisys: Remove POSTCODE macros
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, December 01, 2016 2:34 AM > To: Kershner, David A <david.kersh...@unisys.com> > Cc: driverdev-devel@linuxdriverproject.org; *S-Par-Maintainer > <sparmaintai...@unisys.com>; jes.soren...@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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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? > 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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
