Re: adding can4linux to drivers/char

[Wolfgang Grandegger <wg@grandegger.com>]

On Mon, 30 Sep 2013 09:40:37 +0200, Sebastian Haas
<dev@sebastianhaas.info> wrote:
> 2013/9/29 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.
> Again think about memory (RAM/ROM) as well. We are talking here about
small
> ARM7TDMI stuff and other creepy and limited systems.

Do you have figures? I remember that the a chardev based solution is not
really
*much* better.

>>> 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!
> Sharing definitions and common functions sounds ugly to you? What does
> the candev
> and sja1000dev in Socket CAN does?

OK, pure share is fine but I had ugly #ifdef's in mind.
 
>>> 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.
> Right, and I think a chardev drivers has far less dependencies to
maintain
> then
> the Socket CAN driver. No netdev changes to maintain, iputils stuff or
> changes
> in the candev ;-)
> 
> A reason more trying to share code with a chardev solution!
> 
>> 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.
> Well, some things can't be done cause of the underlying networking
> subsystem
> (namely the queuing) which is perfectly fine for real networking stuff
> (>= IP) but
> not that well for CAN IMHO.

I do not say that can4linux is bad but image we have another CAN interface
in the kernel supporting a *different* set of devices... and we will end
up with such a solution sooner than later, for sure. This means that
people
will finally not have the real choice but are forced to use the interface
supporting their device. It breaks portability! I believe that's a *bad*
solution for the community.

Wolfgang.