Tue, Oct 06, 2015 at 04:54:09PM CEST, john.fastab...@gmail.com wrote: >On 15-10-06 01:14 AM, Jiri Pirko wrote: >> Mon, Oct 05, 2015 at 05:47:09PM CEST, john.fastab...@gmail.com wrote: >>> On 15-10-05 08:35 AM, Jiri Pirko wrote: >>>> Mon, Oct 05, 2015 at 05:29:09PM CEST, john.fastab...@gmail.com wrote: >>>>> On 15-10-05 08:18 AM, Jiri Pirko wrote: >>>>>> Mon, Oct 05, 2015 at 04:58:42PM CEST, and...@lunn.ch wrote: >>>>>>> On Mon, Oct 05, 2015 at 04:55:42PM +0200, Jiri Pirko wrote: >>>>>>>> Mon, Oct 05, 2015 at 04:49:41PM CEST, and...@lunn.ch wrote: >>>>>>>>>>> Are you referring here to messages of the EMAD protocol ? >>>>>>>>> >>>>>>>>> I know nothing about this protocol..... >>>>>>>>> >>>>>>>>> Does it at least use standard Ethernet framing? Source and Destination >>>>>>>>> header and an EtherType which mean EMAD? >>>>>>>> >>>>>>>> Yep, but that does not really matter. I believe we should find >>>>>>>> debugging >>>>>>>> interface which is protocol agnostic. Just arbitrary messages >>>>>>>> monitoring. >>>>>>> >>>>>>> Hi Jiri >>>>>>> >>>>>>> O.K, it is just that you mentioned wireshark. Passing the frames to >>>>>>> network interface taps would make this trivial. >>>>>> >>>>>> That is true. But using netlink+nlmon would do the same. >>>>> >>>>> Also I guess if you go this direction you want to make it generic >>>>> enough for any drivers to use it to snoop software/firmware msgs. This >>>>> is common across many devices. >>>> >>>> Yes, definitelly, this should be something generic to be usable for >>>> every device type. >>>> >>>> >>>>> >>>>> In the past though I've just used ethtool dump commands and some >>>>> "scripts" on top of this to debug devices. And when it got really >>>>> bad wrote some throw away code to debug my issue. I guess it might >>>>> be nice to have something in the kernel to improve this but have >>>>> you considered using the tracing features that already exist? >>>> >>>> Which ones do you have in mind? >>>> >>> >>> I was thinking something like kprobes+bpf to dump a trace and >>> then a lua script in wireshark to parse the input and pretty >>> print it for users. This might get you good-enough support without >>> having to carry it around in the kernel just so we can debug >>> the devices. We could build some libs/pkgs around it in userspace >>> and get it published somewhere so we can all work on it together. >> >> Well, I was thinking rather about some standard interface, not dependent >> on actual kernel internals. >> > > >Sure just throwing out an idea. I suspect whatever interface you have >will include the vendor-id or some other identifier and a set of >parsers in user space to pretty print the msg.
Yes, that is the plan. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
