David Jander wrote: > Hi all, > > On Tuesday 27 December 2005 22:49, Alessandro Rubini wrote: > >>I need to port ocan to support SJA1000 on an ARM device, as a client >>asked for it. Also, another client asked for a 2.6 port, so all of >>this will happen pretty soon (2-3 weeks). I don't know if that makes >>any difference. > > > That could of course make a difference.... eventually. > The problem I see with Ocan is that it has a very different API than all the > others. I know of at least two others, which try to be compatible (or at > least easily portable between) with each other: lincan and can4linux. I am > not sure but I think they started from the same base, and somehow agreed to > stay API-compatible.
Robert Schwebel et al have worked socket based CAN (i.e. implement CAN as _net_ dev, not as char), as consequence you will not have problem with major/minor numbers, duplicated code in drivers for different chips, could share CAN dev between diff processes _without_ misc. third party shared libraies, stacked CAN protocols (CANopen/NMEA2000 could be abstract kernel module)... But currently it is not open for everyone (due to beta status, AFAIK) Alessandro, please check Pengutronix work first, may be it will be helpfull to you to, Also I permit oneself to quotate _you_ ;) from LDDv3 pp6-7: "The three classes are: Character devices A character (char) device is one that can be accessed as a stream of bytes (like a file); a char driver is in charge of implementing this behavior. Such a driver usually implements at least the open, close, read, and write system calls. The text console (/dev/console) and the serial ports (/dev/ttyS0 and friends) are examples of char devices, as they are well represented by the stream abstraction. Char devices are accessed by means of filesystem nodes, such as /dev/tty1 and /dev/lp0. The only relevant difference between a char device and a regular file is that you can always move back and forth in the regular file, whereas most char devices are just data channels, which you can only access sequentially. There exist, nonetheless, char devices that look like data areas, and you can move back and forth in them; for instance, this usually applies to frame grabbers, where the applications can access the whole acquired image using mmap or lseek. Block devices Like char devices, block devices are accessed by filesystem nodes in the /dev directory. A block device is a device (e.g., a disk) that can host a filesystem. In most Unix systems, a block device can only handle I/O operations that transfer one or more whole blocks, which are usually 512 bytes (or a larger power of two) bytes in length. Linux, instead, allows the application to read and write a block device like a char device?it permits the transfer of any number of bytes at a time. As a result, block and char devices differ only in the way data is managed internally by the kernel, and thus in the kernel/driver software interface. Like a char device, each block device is accessed through a filesystem node, and the difference between them is transparent to the user. Block drivers have a completely different interface to the kernel than char drivers. Network interfaces Any network transaction is made through an interface, that is, a device that is able to exchange data with other hosts. Usually, an interface is a hardware device, but it might also be a pure software device, like the loopback interface. A network interface is in charge of sending and receiving data packets, driven by the network subsystem of the kernel, without knowing how individual transactions map to the actual packets being transmitted. Many network connections (especially those using TCP) are stream-oriented, but network devices are, usually, designed around the transmission and receipt of packets. A network driver knows nothing about individual connections; it only handles packets." so CAN _is_ Network interface, but not char device (how it often implemented). P.S. Robert, when I check last time, it was mature enogh, so may be time to open mail-list and svn? -- Regards Andrey Volkov
