On Fri, 10 Mar 2006 10:15:13 +0100 Tilman Schmidt wrote: > Greg KH wrote: > > On Thu, Mar 09, 2006 at 01:18:47PM -0800, Pete Zaitcev wrote: > [...] > >> Symbol names are generally unique. As a USB stack developer, I never saw > >> the file name being useful for anything in the error message, let alone > >> the full path! Always hated them, but never bothered to break spears > >> over the issue. We have better things to do. I just quietly remove > >> debugging printouts from the code I touch. > > > > There's a bit of history here. The dbg(), err(), info() macros came > > from the USB core, back in 2.2 days. Then the whole path of the file > > was not part of __FILE__, but only the single .c file. > > > > With 2.5, __FILE__ changed as part of the build process changes, and we > > added dev_dbg(), dev_info(), and dev_err(), which are a _much_ better > > way to output information from a driver. It provides the exact driver > > and device that is being talked about, and not just a file. > > > > So, ideally I'd like to get rid of the USB macros completly, and use the > > dev_* forms instead. But there are a few places in the USB code that do > > not have a valid device and so they can't be dropped entirely. > > Indeed, and there always will be. > > > Either way, I don't think we need to be making them "prettier" at this > > point in time, but fixing the real problem of using them in the first > > place... > > Do you have specific proposition for that? What might a fix look like? > > > I'll drop this patch for now, and only take the part that adds the new > > dev_* macro. Is that ok for everyone? > > Can't say I'm happy with that. > > > And if anyone wants to notify the kernel-janitors that this would be a > > good thing to do for the USB subsytem, feel free, I'll gladly accept > > those patches. > > Could you explain how to do that?
Just send a full description of the problem/work statement to [EMAIL PROTECTED] (for its info, see https://lists.osdl.org/mailman/listinfo/kernel-janitors), probably including Greg's recommendation(s). --- ~Randy Please use an email client that implements proper (compliant) threading. (You know who you are.) ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel