Luotao Fu wrote: > Hi Wolfgang, > > On Tue, Nov 24, 2009 at 03:46:22PM +0100, Wolfgang Grandegger wrote: >> Hi Fu, >> >> Luotao Fu wrote: >>> Hi folks, >>> >>> I was trying to integrate socketcan control in an application the last days >>> and >>> spent quite a lot of time getting clear how to deal with the netlink >>> interface. >> I can image. Such a library is on my to-do list since a long time, but >> so far I didn't find enough time to implement it. Thanks for the effort. >> > > Ah, luckily we didn't do doubled work. ;-)
Puh, not yet, fortunately. >>> Besides I just couldn't remember the correct order of parameter when using >>> the >>> iproute tool for can ;-). So I stripped some code from the iproute package >>> and >>> put them with some own stuffs together in a library to access can >>> configuration >>> functions with netlink, which I call libsocketcan-nl. (nl stand for >>> netlink, not >>> netherland ;-)). The library provides some simple APIs to do common CAN >>> stuffs, >>> lacking of a proper documentation I'll start here with the content of the >>> header >>> file: >>> int scan_set_restart(const char *name); >> scan_do_restart() would be more appropriate. >> > > Hm, I actually want to keep the name scheme with _set_ and _get_. I'll > consider a better name for this. It's definitely not a set/get property. >>> int scan_set_bitrate(const char *name, __u32 bitrate); >>> int scan_set_restart_ms(const char *name, __u32 restart_ms); >>> int scan_set_ctrlmode(const char *name, __u32 mode, __u32 flags); >>> >>> int scan_get_state(const char *name, int *state); >>> int scan_get_restart_ms(const char *name, __u32 *restart_ms); >>> int scan_get_bittiming(const char *name, struct can_bittiming *bt); >>> int scan_get_ctrlmode(const char *name, struct can_ctrlmode *cm); >>> >>> Usage is quite straight forward. The functions await simply the name of the >>> can >>> interface and, if any, configuration values and return 0 for success and -1 >>> if >>> something went wrong. >>> >>> This library provides some benefits, which the hookup code in iproute >>> doesn't do: >>> * more clear error messages and takes care of special cases, e.g. >>> restarting a >>> device can only be done while the interface is in BUS_OFF. Neither kernel >>> nor >> Hm, you cannot restart the device when it's not bus-off. The driver does >> not allow that. See: >> >> http://lxr.linux.no/#linux+v2.6.31/drivers/net/can/dev.c#L376 >> > > Yeah I know. What I mean was that if one calls "ip link can0 type can > set restart" (no guarantee for correctness of the parameters, I'm still > struggling with this ;-)) while the device is not in BUS_OFF, he will > eventually end up with an EINVAL or EBUSY without knowing why. The > iproute tool cannot do any pre-detection while calling can_parse_opt > function since it's hooked deeply in the iproute given infrastructure > and the kernel simply returns a EBUSY or EINVAL without any error > message in such cases. I myself had to look up in the kernelcode to find > what was really going wrong since I didn't know about the BUS_OFF > limitation. So I add some detection in the library to make clear why > restart is not supposed to work. Addtionally I also added if_up if_down > callbacks into several _set_ callbacks, to make the usage as easy as > possible. Well, yes, I should add some more lines to Documentation/can.txt. Also, keep it simple having in mind that it's especially useful on embedded system (the busybox's "ip" utility does not yet support CAN). Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
