On Mon, 2006-08-14 at 14:38 +0200, Jan-Bernd Themann wrote: > Hi > > Anton Blanchard wrote: > > What is going to be done about the debug infrastructure in the ehea > > driver? The entry and exit traces really need to go, and any other debug > > you think is important to users needs to go into debugfs or something > > similar. > > > > I see a similar issue in the ehca driver that I am in the middle of > > reviewing. > > > > Anton > > This is a statement for the eHEA driver: > > Most of the debug outputs are redundant and we'll remove them > (EDEB_EN / EDEB_EX). We can use the standard mechanism for ethernet devices > (netif_msg_x) in most functions of ehea_main.c as we have the device struct > as a parameter available. However, some debug output mechanism is needed > where the standard mechanism does not work (functions that have no relation > to the dev struct do not have a dev parameter, for example > ehea_hcall_9arg_9ret in ehea_phyp.h) > > The outcome of some internal discussions was that it is not acceptable for > our enterprise users of this type of driver on this target system to need a > recompile / reload of the driver for error analysis, so we need a mechanism > that allows us to switch on / off debug output at runtime. Therefore, we'd > introduce a stripped down version of EDEB.
Well, it might be better if the driver just worked, then your enterprise users wouldn't need debugging output ;) ... But if you think you need that facility then you should look at debugfs, or relayfs, or just plain old printk, rather than implementing something new. cheers -- Michael Ellerman IBM OzLabs wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
