> > I agree this surely isn't *our* convention, but for scsi using > > debugfs [or sysfs] is a common practice for debug purposes. > > > > Also, our HW debug capabilities are highly-customable, and I want to > > have the ability to configure those on the fly [E.g., dynamically > > configuring various HW events to be recorded]. > > Each such configuration involves multiple register writes and reads > > according to user provided inputs. > > I don't really see how to generalize the information collection in a > > way that would benefit anyone else. > > That's basically what everyone says who slaps random crap into debugfs.
True; But assuming that means the suggestion to use debugfs means the content is random crap is a logical fallacy. > >> For your inhouse debugging, you should have oot patch to expose > >> whatever you need. > > > > I don't want in-house debugging capabilities - I want field debug > > capabilities. > > Then it has to use a portable, well defined, set of interfaces. How would you be able to describe something that is completely tied to a specific HW this way. E.g., let's assume you'd want to record some messages that pass between 2 internal processors that match some criteria? While you can probably standardize some format from such a matching [although that too would be very tied to different HW capabilities], the HW pipeline itself can't be abstracted in this case.
