I'm not really familiar with XS wrappers, but on the surface, it appears to provide similar functionality to using a child process and filesystem sematics to read or write. Is there more to it than that?
My present scheme looks like this:
open( CAN, "candump|" );
while( <CAN> ){
# Process captue data here...
}
Do I get anything more by using XS Wrappers?
Ultimately, I'd like to have the socket access so I can use it to perform both reads and writes to the CANbus.
| [reply]
[d/l] |
What I provided *writes* to the CANbus. When I say "wrapper" I don't mean shelling or piping out from perl but calling the can-util functions directly.
If you are familiar with C, have a look at cansend.c (of the distribution I posted) and particularly the cansend(...) function. You will see there how to open the socketCAN and write to it. In candump.c, of can-utils distribution, you will see how they open the socketCAN for reading and read from it (and print to stdout).
If you are familiar with C, again, I suggest that you build up a small library, following can-utils's code, where you provide funcionality like socketCAN_open(interface), socketCAN_close(socket), socketCAN_read(socket), socketCAN_write(socker, data). Then you proceed implementing your sniffer in C utilising these functions.
FInally, write the XS wrapper to call your function. But here you have a major problem: you need to poll the CANbus at regular intervals and when it has data you need to push that back to Perl somehow. One way to do this is via a user-specified Perl callback which is called whenever the bus has data. That's possible and in Net::Ncap you can see how they do it (their XS code is at https://metacpan.org/release/MSISK/Net-Ncap-1.01/source). Others here may have better ideas
The other way is via pure-perl, opening a Socket (in Perl) and do all I describe above in Perl. BUT I don't think they have implemented the socket type AF_CAN which is already specified in include/linux/can.h. So how do you open the socketCAN? Hmm. perhaps posting an issue at https://rt.cpan.org/Public/Dist/Display.html?Name=Socket and ask them what their plan is for socketCAN. Or better, post a patch for AF_CAN to be covered.
Finally, what you have suggested and doing already (piping out to candump) is OK, AFAIC. Although it may suffer if you aim for realtime performance.
So, depending on your C experience and time to invest, chose your route. I suggest the 1st route: building your C library (and don't worry too much about XS as I and others here can help you, and with C obviously). The 2nd route is mostly effortless and ready to use now, as you have already tried it. Check its realtime performance. Edit: Either way you chose, if you have the time, please post an issue about socketCAN at the Socket's bug tracker (Or I can do it sometime in the future).
bw, bliako
| [reply]
[d/l]
[select] |
Thanks for the detailed explanation and clarification. I am conversant in C, and I've already written a lot of the functionality I'm looking for in C for a slightly different platform (the older linuxcan driver). I didn't understand that the wrapper concept was at the C function level, rather than the standalone application level. I should ber able to produce some test function fairly quickly. I will research the XS wrapper scheme, and see what I can come up with. High performance isn't really needed, at least not at the moment, and if it becomes necessary, I'll go full-on C.
| [reply] |