canbus4linux-developers

[Canbus4linux-developers] RFC: CAN for 2.6 kernel subsystem: net or char device

[Andrey V. <and...@us...>]

Hello, Jurgen

I look through your code (and not only your), and have, may be strange, 
next question:

May be you, could told me why everyone who wrote CANbus driver (you, 
peak, kvaser etc) always use char dev, but not netdev for it? May be 
exist some global pitfall, which I couldn't see, to use netdev?

--
Regards
Andrey.

P.S. My job on MPC5200 CAN in progress (chip part nearly to be done),
but I stopped above problem.

[Canbus4linux-developers] Re: RFC: CAN for 2.6 kernel subsystem: net or char device

[<je...@ar...>]

Hi Andrey,
this was my first device driver I've written and the only reason was,
that a netdev driver was more complex as a char dev driver.

Also I think a netdev driver is not the correct way to handle CAN
messages (you can setup IP addresses with ifconfig ?!). But if you want
to handle TCP messages over CAN, than I think a netdev driver is the
first choice.


regards
J=FCrgen



Am Dienstag, den 15.03.2005, 12:41 +0300 schrieb Andrey Volkov:
> Hello, Jurgen
>=20
> I look through your code (and not only your), and have, may be strange,=
=20
> next question:
>=20
> May be you, could told me why everyone who wrote CANbus driver (you,=20
> peak, kvaser etc) always use char dev, but not netdev for it? May be=20
> exist some global pitfall, which I couldn't see, to use netdev?
>=20
> --
> Regards
> Andrey.
>=20
> P.S. My job on MPC5200 CAN in progress (chip part nearly to be done),
> but I stopped above problem.
>=20

Re: [Canbus4linux-developers] Re: RFC: CAN for 2.6 kernel subsystem: net or char device

[Andrey V. <and...@us...>]

Jürgen wrote:
> Hi Andrey,
> this was my first device driver I've written and the only reason was,
> that a netdev driver was more complex as a char dev driver.
> 
> Also I think a netdev driver is not the correct way to handle CAN
> messages (you can setup IP addresses with ifconfig ?!). 

No Jürgen, you're wrong about netdev: netdev != eth with TCP/IP :),

Quotation from Linux Device Drivers:

"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."

Pay attention to last phrase in netdev part.

 > But if you want
> to handle TCP messages over CAN, than I think a netdev driver is the
> first choice.
NICHT DOCH! Ich bin nicht so toll :), I wish can proto over CAN socket 
only. Check this link 
http://www.linutronix.de/data/linux-2.6.11-can.diff for clearance.

Andrey
> 
> 
> Am Dienstag, den 15.03.2005, 12:41 +0300 schrieb Andrey Volkov:
> 
>>Hello, Jurgen
>>
>>I look through your code (and not only your), and have, may be strange, 
>>next question:
>>
>>May be you, could told me why everyone who wrote CANbus driver (you, 
>>peak, kvaser etc) always use char dev, but not netdev for it? May be 
>>exist some global pitfall, which I couldn't see, to use netdev?
>>
>>--
>>Regards
>>Andrey.
>>
>>P.S. My job on MPC5200 CAN in progress (chip part nearly to be done),
>>but I stopped above problem.
>>
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
> _______________________________________________
> Canbus4linux-developers mailing list
> Can...@li...
> https://lists.sourceforge.net/lists/listinfo/canbus4linux-developers
>