Re: adding can4linux to drivers/char

[Wolfgang Grandegger <wg@grandegger.com>]

On 09/29/2013 06:28 PM, Heinz-Jürgen Oertel wrote:
> 
> Hello
> 
> Am Samstag, 21. September 2013, 21:55:45 schrieb Wolfgang Grandegger:
>> I think you need *strong* arguments to get it accepted. 
> 
> I have some good arguments for this kind of driver
> - it is much more simple in design than others,
>   simplicity is one of the Linux design goals
> - It has a simple user API
> - It does not need any other infrastructure than the kernel API
> - It is mature

Well, the question is in what respect it's (much) better than the
existing Linux-CAN. I can imagine some performance benefits on very low
end systems, if at all.

> I agree, it would be nice to share the low level CAN controller related 
> experiences of the developers. That is may be something we can share if we 
> could agree of a set of CAN controller header files with shared register 
> #defines. And a set of very basic functions like initialize and activate CAN, 
> set acceptance filters, transmit and receive, read out error register or 
> whatever.

Sounds ugly!

> But to stay simple, I don't like the idea to have another additional layer 
> around SocketCAN as layer below the can4linux API.
> 
> Linux offers real diversity on the desktop, why not with drivers? Linux also 
> has different sound devices and architectures.  Why not offering two different 
> CAN driver concepts to the application programmer,
> let she decide what to use.


It's also about maintenance. It's real work to keep a driver in the
kernel up-to-date, to review and accept new drivers, etc., not only for
the initial submitter.

There are missing bits and pieces in Linux-CAN, e.g. hardware filter
support, improved bus-off handling or even bitrate detection. That's
also not a strong argument for can4linux. Just contribute them to Linux-CAN.

Wolfgang.