Wolfgang Grandegger wrote: > Hi Fu, > > Luotao Fu wrote: >> Hi Vlasdiv, >> >> On Wed, Nov 25, 2009 at 06:30:07PM +0100, [email protected] wrote: >>> Hi, >>> very nice idea! >>> >>> The SocketCAN version of our IXXAT CANopen Stack SW is currently >>> compatible >>> to the SysFS version. We need however to set CAN up and down directly >>> from the Stack, not using the ifconfig. So I was forced to implement >>> corresponding ioctl calls with IFF_UP etc. And netlink interface is >>> quite more complex, if you cannon use "ip" and need to make CAN control >>> stuff directly from your SW (I know, that is not UNIX-way, that's >>> life)... >>> >> there're actually if_up/down callbacks in the lib, which also uses >> netlink interface and awaits only the name of the device as parameter. >> It's however used as static internally for now, since it's not strict >> can-relevant. I think there'd be other libraries in the wild, which >> simply do if_up/down stuff, didn't check though. >> >>> Such a user space component can make things really easier for me, as a >>> CANopen SW maintainer under SocketCAN. If I can use someuser space >>> library >>> "libsocketcan" to: >>> >>> - start/stop CAN >> yeah, start with >> scan_do_restart(const char* name) >> stop alias driving down the interface is there but used as static, I'll >> make a wrapper with proper name for this. > > Hm, the name "restart" is somehow reserved for bus-off recovery. Even if > the name is not well chosen, we should use another name for down/up, > e.g. scan_do_down_up() to make that clear, if we need that at all. Or > have I missed something?
Just looked to the code. scan_do_restart() just does the bus-off recovery if appropriate. But I realized that the scan_set_* functions do stop the device before setting the property. That's dangerous and error prune and therefore we did not allow it in the kernel. It's up to the user/application to handle up/down properly. Furthermore, these functions seem to start the device even if it was not up before. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
