Re: Informations About CAN API of the Linux Kernel

Re: Informations About CAN API of the Linux Kernel

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

On 03/06/2013 03:51 PM, Sako Youssouf wrote:
> I'm an engineer of a French company, Renault Trucks Defense. We are 
> Militaries cars makers. We are currently testing the CAN API of 
> Linux. I found your article "SocketCAN - The official CAN API of the 
> Linux kernel" on internet and after reading it I have some 
> questions.

Please use the linux-can mailinglist (Cc'ed), however no HTML mails are
allowed on that list.

> About CAN frame reception:
> 
> 1.       In a case of a controller with a single receive buffer . if 
> a new CAN frame arrives and the previous one has not yet been 
> treated, what happens? is the previous one is just lost? Or the 
> kernel has a way to handle that situation.

In linux-can we make use of the Linux networking driver model. This
means if a frame is received from the hardware, it read from the receive
buffer by the driver as soon as possible and pushed into the Linux
networking stack. If the driver fails to do so, the frame of course is lost.

However there is a queue between you application and the kernel, so that
several CAN frames can be on-the-fly between the driver and your
application.

> 2.       In a case of a hardware with a large RX FIFO,  when we call 
> the read function on userspace program, is it possible to know how 
> many frames are available on the RX queue?

There's no way to figure out the number of frames in the RX queue of the
hardware. It might be possible to figure out the number of frames in the
software queue between the kernel and your application. What's your
usecae? What do you want to do with that information?

> And a last question, do you have information about when the Linux
> API for SAE J1939 will be available?

Kurt (Cc'ed) can probably comment on this.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

RE: Informations About CAN API of the Linux Kernel

[Sako Youssouf]

What's your usecae? What do you want to do with that information?

Actually I'm in a multithreaded application and my goal is to lose no frame.
If I had direct access to the hardware, I would go  get the new frame after hardware interrupt.
But I think it's not possible. So I want to find the better way to get all frames in a multithreaded application. 

Youssouf
_________________________________________________










Youssouf SAKO
System engineer
S +33 1 73 19 07 45
+ youssouf.sako@renault-trucks.com
www.renault-trucks-defense.com

15 bis Allée des Marronniers
SAT TER 1 15
SATORY - CS 30502
78 008 VERSAILLES Cedex
France



-----Original Message-----
From: Marc Kleine-Budde [mailto:mkl@pengutronix.de] 
Sent: mercredi 6 mars 2013 16:42
To: Sako Youssouf
Cc: linux-can@vger.kernel.org; Kurt Van Dijck
Subject: Re: Informations About CAN API of the Linux Kernel

On 03/06/2013 03:51 PM, Sako Youssouf wrote:
> I'm an engineer of a French company, Renault Trucks Defense. We are 
> Militaries cars makers. We are currently testing the CAN API of 
> Linux. I found your article "SocketCAN - The official CAN API of the 
> Linux kernel" on internet and after reading it I have some 
> questions.

Please use the linux-can mailinglist (Cc'ed), however no HTML mails are
allowed on that list.

> About CAN frame reception:
> 
> 1.       In a case of a controller with a single receive buffer . if 
> a new CAN frame arrives and the previous one has not yet been 
> treated, what happens? is the previous one is just lost? Or the 
> kernel has a way to handle that situation.

In linux-can we make use of the Linux networking driver model. This
means if a frame is received from the hardware, it read from the receive
buffer by the driver as soon as possible and pushed into the Linux
networking stack. If the driver fails to do so, the frame of course is lost.

However there is a queue between you application and the kernel, so that
several CAN frames can be on-the-fly between the driver and your
application.

> 2.       In a case of a hardware with a large RX FIFO,  when we call 
> the read function on userspace program, is it possible to know how 
> many frames are available on the RX queue?

There's no way to figure out the number of frames in the RX queue of the
hardware. It might be possible to figure out the number of frames in the
software queue between the kernel and your application. What's your
usecae? What do you want to do with that information?

> And a last question, do you have information about when the Linux
> API for SAE J1939 will be available?

Kurt (Cc'ed) can probably comment on this.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

Re: Informations About CAN API of the Linux Kernel

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On 03/06/2013 05:03 PM, Sako Youssouf wrote:
> What's your usecae? What do you want to do with that information?
> 
> Actually I'm in a multithreaded application and my goal is to lose no
> frame. If I had direct access to the hardware, I would go  get the
> new frame after hardware interrupt. But I think it's not possible. So
> I want to find the better way to get all frames in a multithreaded
> application.

The driver takes care of loosing no frame. In you application you just
have to read() or recv() from the socket. It doesn't matter if you app
is multithreaded or not.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

RE: Informations About CAN API of the Linux Kernel

[Sako Youssouf]

Ok! And do you know the way to know how many frames are in the Queue? 

Youssouf

_________________________________________________










Youssouf SAKO
System engineer
S +33 1 73 19 07 45
+ youssouf.sako@renault-trucks.com
www.renault-trucks-defense.com

15 bis Allée des Marronniers
SAT TER 1 15
SATORY - CS 30502
78 008 VERSAILLES Cedex
France



-----Original Message-----
From: Marc Kleine-Budde [mailto:mkl@pengutronix.de] 
Sent: mercredi 6 mars 2013 17:18
To: Sako Youssouf
Cc: linux-can@vger.kernel.org; Kurt Van Dijck
Subject: Re: Informations About CAN API of the Linux Kernel

On 03/06/2013 05:03 PM, Sako Youssouf wrote:
> What's your usecae? What do you want to do with that information?
> 
> Actually I'm in a multithreaded application and my goal is to lose no
> frame. If I had direct access to the hardware, I would go  get the
> new frame after hardware interrupt. But I think it's not possible. So
> I want to find the better way to get all frames in a multithreaded
> application.

The driver takes care of loosing no frame. In you application you just
have to read() or recv() from the socket. It doesn't matter if you app
is multithreaded or not.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

Re: Informations About CAN API of the Linux Kernel

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On 03/06/2013 05:25 PM, Sako Youssouf wrote:
> Ok! And do you know the way to know how many frames are in the Queue? 

Why do you need this information?

Just keep reading until read() blocks. If you don't like blocking, put
the socket into non blocking mode and read() will return -EAGAIN.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

RE: Informations About CAN API of the Linux Kernel

[Sako Youssouf]

Ok! I'll do that.

Thanks for your help Marc. 

_________________________________________________

Youssouf SAKO
System engineer
S +33 1 73 19 07 45
+ youssouf.sako@renault-trucks.com
www.renault-trucks-defense.com

15 bis Allée des Marronniers
SAT TER 1 15
SATORY - CS 30502
78 008 VERSAILLES Cedex
France

Re: Informations About CAN API of the Linux Kernel

[Kurt Van Dijck]

On Wed, Mar 06, 2013 at 04:42:04PM +0100, Marc Kleine-Budde wrote:
> On 03/06/2013 03:51 PM, Sako Youssouf wrote:
> > I'm an engineer of a French company, Renault Trucks Defense. We are 
> > Militaries cars makers. We are currently testing the CAN API of 
> > Linux. I found your article "SocketCAN - The official CAN API of the 
> > Linux kernel" on internet and after reading it I have some 
> > questions.
> 
> 
[...]
> > And a last question, do you have information about when the Linux
> > API for SAE J1939 will be available?
> 
> Kurt (Cc'ed) can probably comment on this.

The J1939 API that is available on gitorious[1] is waiting for acceptance.
The API has not changed for almost a year now, and is working.
The J1939 API is quite different from raw CAN, since J1939 adds an
addressing scheme. This makes it hard for non-J1939 users to
judge about the usefullness of the API.
Therefore, it's important that users of the J1939 stack share their
opinion about it.
Therefore, also your opinion matters and may contribute to the acceptance.
If you find the J1939 stack usefull of course :-)

Kind regards,
Kurt

[1]:  http://gitorious.org/~kurt-vd/linux-can/linux-can-j1939

> 
> Marc
> -- 
> Pengutronix e.K.                  | Marc Kleine-Budde           |
> Industrial Linux Solutions        | Phone: +49-231-2826-924     |
> Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
> 
> 
> 



-- 
Kurt Van Dijck
GRAMMER EiA ELECTRONICS
http://www.eia.be
kurt.van.dijck@eia.be
+32-38708534

Re: Informations About CAN API of the Linux Kernel

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

Hello Kurt,

On 03/07/2013 01:40 PM, Kurt Van Dijck wrote:
> On Wed, Mar 06, 2013 at 04:42:04PM +0100, Marc Kleine-Budde wrote:
>> On 03/06/2013 03:51 PM, Sako Youssouf wrote:
>>> I'm an engineer of a French company, Renault Trucks Defense. We are 
>>> Militaries cars makers. We are currently testing the CAN API of 
>>> Linux. I found your article "SocketCAN - The official CAN API of the 
>>> Linux kernel" on internet and after reading it I have some 
>>> questions.
>>
>>
> [...]
>>> And a last question, do you have information about when the Linux
>>> API for SAE J1939 will be available?
>>
>> Kurt (Cc'ed) can probably comment on this.
> 
> The J1939 API that is available on gitorious[1] is waiting for acceptance.
> The API has not changed for almost a year now, and is working.
> The J1939 API is quite different from raw CAN, since J1939 adds an
> addressing scheme. This makes it hard for non-J1939 users to
> judge about the usefullness of the API.
> Therefore, it's important that users of the J1939 stack share their
> opinion about it.
> Therefore, also your opinion matters and may contribute to the acceptance.
> If you find the J1939 stack usefull of course :-)

Would it be possible to add the j1939 support to staging? I mean from
the technical and from the political (is staging reserved for drivers
only?) point of view.

regards,
Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Informations About CAN API of the Linux Kernel

[Kurt Van Dijck]

On Fri, Mar 08, 2013 at 09:55:41AM +0100, Marc Kleine-Budde wrote:
> Hello Kurt,
> 
> On 03/07/2013 01:40 PM, Kurt Van Dijck wrote:
> > On Wed, Mar 06, 2013 at 04:42:04PM +0100, Marc Kleine-Budde wrote:
> >> On 03/06/2013 03:51 PM, Sako Youssouf wrote:
> >>> I'm an engineer of a French company, Renault Trucks Defense. We are 
> >>> Militaries cars makers. We are currently testing the CAN API of 
> >>> Linux. I found your article "SocketCAN - The official CAN API of the 
> >>> Linux kernel" on internet and after reading it I have some 
> >>> questions.
> >>
> >>
> > [...]
> >>> And a last question, do you have information about when the Linux
> >>> API for SAE J1939 will be available?
> >>
> >> Kurt (Cc'ed) can probably comment on this.
> > 
> > The J1939 API that is available on gitorious[1] is waiting for acceptance.
> > The API has not changed for almost a year now, and is working.
> > The J1939 API is quite different from raw CAN, since J1939 adds an
> > addressing scheme. This makes it hard for non-J1939 users to
> > judge about the usefullness of the API.
> > Therefore, it's important that users of the J1939 stack share their
> > opinion about it.
> > Therefore, also your opinion matters and may contribute to the acceptance.
> > If you find the J1939 stack usefull of course :-)
> 
> Would it be possible to add the j1939 support to staging? I mean from
> the technical and from the political (is staging reserved for drivers
> only?) point of view.

That is a good idea.
Technically, staging is underneath drivers/, which answers the political
question: yes, it's for drivers probably.

Could I just mark j1939 as "EXPERIMENTAL" in Kconfig.
I think that is what I've seen most for 'unstable concepts'.
AFAIK this means that you should take care yourself of API changes.
This is probably fine for the current (few) users of the stack,
and warns new users enough?

Oliver, do you feel allright with such approach?

Kind regards,
Kurt

> 
> regards,
> Marc
> -- 
> Pengutronix e.K.                  | Marc Kleine-Budde           |
> Industrial Linux Solutions        | Phone: +49-231-2826-924     |
> Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
> 



-- 
Kurt Van Dijck
GRAMMER EiA ELECTRONICS
http://www.eia.be
kurt.van.dijck@eia.be
+32-38708534

Re: Informations About CAN API of the Linux Kernel

[Oliver Hartkopp]

Am 08.03.2013 11:05, schrieb Kurt Van Dijck:

>>> The J1939 API that is available on gitorious[1] is waiting for acceptance.
>>> The API has not changed for almost a year now, and is working.
>>> The J1939 API is quite different from raw CAN, since J1939 adds an
>>> addressing scheme. This makes it hard for non-J1939 users to
>>> judge about the usefullness of the API.

Yes. Unfortunately.

>>> Therefore, it's important that users of the J1939 stack share their
>>> opinion about it.
>>> Therefore, also your opinion matters and may contribute to the acceptance.
>>> If you find the J1939 stack usefull of course :-)

Indeed user feedback is really required.

>>
>> Would it be possible to add the j1939 support to staging? I mean from
>> the technical and from the political (is staging reserved for drivers
>> only?) point of view.
>
> That is a good idea.
> Technically, staging is underneath drivers/, which answers the political
> question: yes, it's for drivers probably.

Please check:

http://www.kroah.com/log/linux/linux-staging-update.html

It's for "drivers" and "filesystems".

You don't need to modify the kernel infrastructure to add drivers and
filesystems - but you need to change infrastructure to add new networking
functionalities.

Therefore i don't think, that this would work with the staging approach.

Btw. how can we gain more interest and users to the evaluation of Kurts j1939
stack? I remember about 3 persons asking about it (even about details) - what
happened to them?

Regards,
Oliver

Re: Informations About CAN API of the Linux Kernel

[Kurt Van Dijck]

On Fri, Mar 08, 2013 at 01:04:40PM +0100, Oliver Hartkopp wrote:
> Am 08.03.2013 11:05, schrieb Kurt Van Dijck:
> 
> >>>The J1939 API that is available on gitorious[1] is waiting for acceptance.
> >>>The API has not changed for almost a year now, and is working.
> >>>The J1939 API is quite different from raw CAN, since J1939 adds an
> >>>addressing scheme. This makes it hard for non-J1939 users to
> >>>judge about the usefullness of the API.
> 
> Yes. Unfortunately.
> 
> >>>Therefore, it's important that users of the J1939 stack share their
> >>>opinion about it.
> >>>Therefore, also your opinion matters and may contribute to the acceptance.
> >>>If you find the J1939 stack usefull of course :-)
> 
> Indeed user feedback is really required.
> 
> >>
> >>Would it be possible to add the j1939 support to staging? I mean from
> >>the technical and from the political (is staging reserved for drivers
> >>only?) point of view.
> >
> >That is a good idea.
> >Technically, staging is underneath drivers/, which answers the political
> >question: yes, it's for drivers probably.
> 
> Please check:
> 
> http://www.kroah.com/log/linux/linux-staging-update.html
> 
> It's for "drivers" and "filesystems".
> 
> You don't need to modify the kernel infrastructure to add drivers and
> filesystems - but you need to change infrastructure to add new networking
> functionalities.
> 
> Therefore i don't think, that this would work with the staging approach.
> 
> Btw. how can we gain more interest and users to the evaluation of Kurts j1939
> stack? I remember about 3 persons asking about it (even about details) - what
> happened to them?

So how about
http://lxr.linux.no/linux+v3.8.2/init/Kconfig#L35 ?
I get the impression that if we let J1939 depend on EXPERIMENTAL, then
we are close to a stack that:
* get attention easily.
* is easy to evaluate due to the mainline inclusion.

Kind regards,
Kurt

Re: Informations About CAN API of the Linux Kernel

[Kurt Van Dijck]

Just got Robert Schwebel's email.
You may forget this one.
> 
> So how about
> http://lxr.linux.no/linux+v3.8.2/init/Kconfig#L35 ?
...

Re: Informations About CAN API of the Linux Kernel

[Yegor Yefremov]

On Fri, Mar 8, 2013 at 1:04 PM, Oliver Hartkopp
<oliver.hartkopp@volkswagen.de> wrote:
> Am 08.03.2013 11:05, schrieb Kurt Van Dijck:
>
>
>>>> The J1939 API that is available on gitorious[1] is waiting for
>>>> acceptance.
>>>> The API has not changed for almost a year now, and is working.
>>>> The J1939 API is quite different from raw CAN, since J1939 adds an
>>>> addressing scheme. This makes it hard for non-J1939 users to
>>>> judge about the usefullness of the API.
>
>
> Yes. Unfortunately.
>
>
>>>> Therefore, it's important that users of the J1939 stack share their
>>>> opinion about it.
>>>> Therefore, also your opinion matters and may contribute to the
>>>> acceptance.
>>>> If you find the J1939 stack usefull of course :-)
>
>
> Indeed user feedback is really required.
>
>
>>>
>>> Would it be possible to add the j1939 support to staging? I mean from
>>> the technical and from the political (is staging reserved for drivers
>>> only?) point of view.
>>
>>
>> That is a good idea.
>> Technically, staging is underneath drivers/, which answers the political
>> question: yes, it's for drivers probably.
>
>
> Please check:
>
> http://www.kroah.com/log/linux/linux-staging-update.html
>
> It's for "drivers" and "filesystems".
>
> You don't need to modify the kernel infrastructure to add drivers and
> filesystems - but you need to change infrastructure to add new networking
> functionalities.
>
> Therefore i don't think, that this would work with the staging approach.
>
> Btw. how can we gain more interest and users to the evaluation of Kurts
> j1939
> stack?

What about creating a small k1939 howto here http://elinux.org/CAN_Bus
Then we could at least try G+ channel to get attention. There are many
automation engineers.

Yegor

Re: Informations About CAN API of the Linux Kernel

[Kurt Van Dijck]

On Fri, Mar 08, 2013 at 02:27:18PM +0100, Yegor Yefremov wrote:
> On Fri, Mar 8, 2013 at 1:04 PM, Oliver Hartkopp
> <oliver.hartkopp@volkswagen.de> wrote:
> > Am 08.03.2013 11:05, schrieb Kurt Van Dijck:
> >
> >
> 
> What about creating a small k1939 howto here http://elinux.org/CAN_Bus
> Then we could at least try G+ channel to get attention. There are many
> automation engineers.

Your suggestion makes sense regardless of the outcome of the Kconfig discussion.

I'll try to address that.

Kind regards,
Kurt

Re: Informations About CAN API of the Linux Kernel

[Oliver Hartkopp]

On 11.03.2013 10:31, Kurt Van Dijck wrote:

> On Fri, Mar 08, 2013 at 02:27:18PM +0100, Yegor Yefremov wrote:
>> On Fri, Mar 8, 2013 at 1:04 PM, Oliver Hartkopp
>> <oliver.hartkopp@volkswagen.de> wrote:
>>> Am 08.03.2013 11:05, schrieb Kurt Van Dijck:
>>>
>>>
>>
>> What about creating a small k1939 howto here http://elinux.org/CAN_Bus
>> Then we could at least try G+ channel to get attention. There are many
>> automation engineers.
> 
> Your suggestion makes sense regardless of the outcome of the Kconfig discussion.
> 


Yes. Great idea.

Especially as all the announcements about the support of

- Android
- CAN utils
- Python
- CAN FD
- J1939
- ISO15765-2 (w CAN FD too)
- CAN Gateways
- etc

get lost on the mailing list ...

It's hard to check the ML archives so i really would appreciate to have a
general overview about SocketCAN and it's dedicated projects.

http://elinux.org/CAN_Bus looks to be a good place for that.

If it's ok for the other guys here on the ML how can i contribute to the wiki?

Just create an account and go for it?

Best regards,
Oliver

Re: Informations About CAN API of the Linux Kernel

[Yegor Yefremov]

On Mon, Mar 11, 2013 at 11:03 AM, Oliver Hartkopp
<socketcan@hartkopp.net> wrote:
> On 11.03.2013 10:31, Kurt Van Dijck wrote:
>
>> On Fri, Mar 08, 2013 at 02:27:18PM +0100, Yegor Yefremov wrote:
>>> On Fri, Mar 8, 2013 at 1:04 PM, Oliver Hartkopp
>>> <oliver.hartkopp@volkswagen.de> wrote:
>>>> Am 08.03.2013 11:05, schrieb Kurt Van Dijck:
>>>>
>>>>
>>>
>>> What about creating a small k1939 howto here http://elinux.org/CAN_Bus
>>> Then we could at least try G+ channel to get attention. There are many
>>> automation engineers.
>>
>> Your suggestion makes sense regardless of the outcome of the Kconfig discussion.
>>
>
>
> Yes. Great idea.
>
> Especially as all the announcements about the support of
>
> - Android

I'll can take care about this.

> - CAN utils
> - Python

I've made a small howto for Python support based on the example in the
patch: https://libbits.wordpress.com/2012/05/22/socketcan-support-in-python/
So I could place it on the wiki too.

> - CAN FD
> - J1939
> - ISO15765-2 (w CAN FD too)
> - CAN Gateways
> - etc
>
> get lost on the mailing list ...
>
> It's hard to check the ML archives so i really would appreciate to have a
> general overview about SocketCAN and it's dedicated projects.
>
> http://elinux.org/CAN_Bus looks to be a good place for that.
>
> If it's ok for the other guys here on the ML how can i contribute to the wiki?
>
> Just create an account and go for it?

Yes.

Yegor

Re: Informations About CAN API of the Linux Kernel

[Kurt Van Dijck]

I just added the J1939 page [1].
There's Still a lot to do ...

[1]: http://elinux.org/J1939

On Mon, Mar 11, 2013 at 11:21:21AM +0100, Yegor Yefremov wrote:
> On Mon, Mar 11, 2013 at 11:03 AM, Oliver Hartkopp
> <socketcan@hartkopp.net> wrote:
> > On 11.03.2013 10:31, Kurt Van Dijck wrote:
> >
> >> On Fri, Mar 08, 2013 at 02:27:18PM +0100, Yegor Yefremov wrote:
> >>> On Fri, Mar 8, 2013 at 1:04 PM, Oliver Hartkopp
> >>> <oliver.hartkopp@volkswagen.de> wrote:
> >>>> Am 08.03.2013 11:05, schrieb Kurt Van Dijck:
> >>>>
> >>>>
> >>>
> >>> What about creating a small k1939 howto here http://elinux.org/CAN_Bus
> >>> Then we could at least try G+ channel to get attention. There are many
> >>> automation engineers.
> >>
> >> Your suggestion makes sense regardless of the outcome of the Kconfig discussion.
> >>
> >
> >
> > Yes. Great idea.
> >
> > Especially as all the announcements about the support of
> >
> > - Android
> 
> I'll can take care about this.
> 
> > - CAN utils
> > - Python
> 
> I've made a small howto for Python support based on the example in the
> patch: https://libbits.wordpress.com/2012/05/22/socketcan-support-in-python/
> So I could place it on the wiki too.
> 
> > - CAN FD
> > - J1939
> > - ISO15765-2 (w CAN FD too)
> > - CAN Gateways
> > - etc
> >
> > get lost on the mailing list ...
> >
> > It's hard to check the ML archives so i really would appreciate to have a
> > general overview about SocketCAN and it's dedicated projects.
> >
> > http://elinux.org/CAN_Bus looks to be a good place for that.
> >
> > If it's ok for the other guys here on the ML how can i contribute to the wiki?
> >
> > Just create an account and go for it?
> 
> Yes.
> 
> Yegor
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Kurt Van Dijck
GRAMMER EiA ELECTRONICS
http://www.eia.be
kurt.van.dijck@eia.be
+32-38708534

Re: Informations About CAN API of the Linux Kernel

[Heinz-Jürgen Oertel]

Am Montag 11 März 2013, 11:03:46 schrieb Oliver Hartkopp:
> It's hard to check the ML archives so i really would appreciate to have a
> general overview about SocketCAN and it's dedicated projects.
> 
> http://elinux.org/CAN_Bus looks to be a good place for that.

While the idea to collect information in a more structured way is very good,
I see that we split resources with a new CAN wiki site.
http://www.can-wiki.info exists
and
http://www.can-wiki.info/doku.php?id=can_higher_layer_protocols:j1939

Regards
    Heinz

Re: Informations About CAN API of the Linux Kernel

[Wolfgang Grandegger]

On 03/14/2013 09:04 AM, Heinz-Jürgen Oertel wrote:
> Am Montag 11 März 2013, 11:03:46 schrieb Oliver Hartkopp:
>> It's hard to check the ML archives so i really would appreciate to have a
>> general overview about SocketCAN and it's dedicated projects.
>>
>> http://elinux.org/CAN_Bus looks to be a good place for that.
> 
> While the idea to collect information in a more structured way is very good,
> I see that we split resources with a new CAN wiki site.
> http://www.can-wiki.info exists
> and
> http://www.can-wiki.info/doku.php?id=can_higher_layer_protocols:j1939

Why not using the Wiki interface of https://gitorious.org/linux-can?

Wolfgang.

Re: Informations About CAN API of the Linux Kernel

[Heinz-Jürgen Oertel]

Am Donnerstag 14 März 2013, 09:28:25 schrieb Wolfgang Grandegger:
> On 03/14/2013 09:04 AM, Heinz-Jürgen Oertel wrote:
> > Am Montag 11 März 2013, 11:03:46 schrieb Oliver Hartkopp:
> >> It's hard to check the ML archives so i really would appreciate to have a
> >> general overview about SocketCAN and it's dedicated projects.
> >>
> >> http://elinux.org/CAN_Bus looks to be a good place for that.
> > 
> > While the idea to collect information in a more structured way is very good,
> > I see that we split resources with a new CAN wiki site.
> > http://www.can-wiki.info exists
> > and
> > http://www.can-wiki.info/doku.php?id=can_higher_layer_protocols:j1939
> 
> Why not using the Wiki interface of https://gitorious.org/linux-can?
> 
> Wolfgang.
> 

CAN-Wiki is more CAN technology related,
whilst e.g.  https://gitorious.org/linux-can
would be Linux software related.

Heinz

Re: Informations About CAN API of the Linux Kernel

[Heinz-Jürgen Oertel]

Am Donnerstag 14 März 2013, 09:41:28 schrieb Heinz-Jürgen Oertel:

> 
> CAN-Wiki is more CAN technology related,
> whilst e.g.  https://gitorious.org/linux-can
> would be Linux software related.
> 
> Heinz

can-wiki.info is off-line :-(
Was it me?

 Heinz

Re: Informations About CAN API of the Linux Kernel

[Kurt Van Dijck]

> > >> It's hard to check the ML archives so i really would appreciate to have a
> > >> general overview about SocketCAN and it's dedicated projects.
> > 
...
> > Why not using the Wiki interface of https://gitorious.org/linux-can?
> 
> CAN-Wiki is more CAN technology related,
> whilst e.g.  https://gitorious.org/linux-can
> would be Linux software related.

Summarizing, the wiki interface of gitorious.org is appropriate for
socketCAN specific howto's and such?

Kind regards,
Kurt

Re: Informations About CAN API of the Linux Kernel

[Yegor Yefremov]

On Thu, Mar 14, 2013 at 12:00 PM, Kurt Van Dijck <kurt.van.dijck@eia.be> wrote:
>> > >> It's hard to check the ML archives so i really would appreciate to have a
>> > >> general overview about SocketCAN and it's dedicated projects.
>> >
> ...
>> > Why not using the Wiki interface of https://gitorious.org/linux-can?
>>
>> CAN-Wiki is more CAN technology related,
>> whilst e.g.  https://gitorious.org/linux-can
>> would be Linux software related.
>
> Summarizing, the wiki interface of gitorious.org is appropriate for
> socketCAN specific howto's and such?

I find elinux.org useful, because it's a very popular wiki for various
embedded Linux projects with tons of howtos etc. and it provides
familiar wikipedia look&feel.  I also find, that CAN-Wiki is more CAN
technology related (there is no mention about SocketCAN).

Yegor

Re: Informations About CAN API of the Linux Kernel

[Heinz-Jürgen Oertel]

Am Donnerstag 14 März 2013, 13:25:49 schrieb Yegor Yefremov:
> I also find, that CAN-Wiki is more CAN
> technology related (there is no mention about SocketCAN).

Yegor
That is for sure not true. But I can not prove it currently.

 Heinz 

Re: Informations About CAN API of the Linux Kernel

[Heinz-Jürgen Oertel]

Am Donnerstag 14 März 2013, 13:25:49 schrieb Yegor Yefremov:
> I also find, that CAN-Wiki is more CAN
> technology related (there is no mention about SocketCAN).
> 
> Yegor

A SocketCAN link is now in.
But anyway, it is a wiki. It lives from user contributions.
If something you like to see isn't there, add it.

Best regards
     Heinz

Re: Informations About CAN API of the Linux Kernel

[Robert Schwebel]

Hi Kurt,

On Fri, Mar 08, 2013 at 11:05:48AM +0100, Kurt Van Dijck wrote:
> Could I just mark j1939 as "EXPERIMENTAL" in Kconfig.
> I think that is what I've seen most for 'unstable concepts'.

EXPERIMENTAL is considered to be deprecated and might be removed from
the kernel, so I wouldn't go down that road. Staging sounds right.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Informations About CAN API of the Linux Kernel

[Kurt Van Dijck]

On Fri, Mar 08, 2013 at 01:51:23PM +0100, Robert Schwebel wrote:
> Hi Kurt,
> 
> On Fri, Mar 08, 2013 at 11:05:48AM +0100, Kurt Van Dijck wrote:
> > Could I just mark j1939 as "EXPERIMENTAL" in Kconfig.
> > I think that is what I've seen most for 'unstable concepts'.
> 
> EXPERIMENTAL is considered to be deprecated and might be removed from
> the kernel, so I wouldn't go down that road. Staging sounds right.

I see.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle?id=v3.9-rc2#n549

Is such thing then appropriate?

--
diff --git a/net/can/j1939/Kconfig b/net/can/j1939/Kconfig
index 74d2a86..0db6545 100644
--- a/net/can/j1939/Kconfig
+++ b/net/can/j1939/Kconfig
@@ -3,7 +3,7 @@
 #
 
 config CAN_J1939
-	tristate "SAE J1939"
+	tristate "SAE J1939 (unstable API)"
 	depends on CAN
 	---help---
 	  SAE J1939
@@ -12,6 +12,7 @@ config CAN_J1939
 	  The relevant parts in kernel are
 	  SAE j1939-21 (datalink & transport protocol)
 	  & SAE j1939-81 (network management).
+	  Big fat warning: The API is yet unstable!
 
 config CAN_J1939_DEBUG
 	bool "debug SAE J1939"

Re: Informations About CAN API of the Linux Kernel

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

On 03/11/2013 10:29 AM, Kurt Van Dijck wrote:
> 
> 
> On Fri, Mar 08, 2013 at 01:51:23PM +0100, Robert Schwebel wrote:
>> Hi Kurt,
>>
>> On Fri, Mar 08, 2013 at 11:05:48AM +0100, Kurt Van Dijck wrote:
>>> Could I just mark j1939 as "EXPERIMENTAL" in Kconfig.
>>> I think that is what I've seen most for 'unstable concepts'.
>>
>> EXPERIMENTAL is considered to be deprecated and might be removed from
>> the kernel, so I wouldn't go down that road. Staging sounds right.
> 
> I see.
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle?id=v3.9-rc2#n549
> 
> Is such thing then appropriate?

Does j1939 have a protocol number? Probably. If so, we shouldn't use the
"next free" one for an experimental protocol.

Marc

> 
> --
> diff --git a/net/can/j1939/Kconfig b/net/can/j1939/Kconfig
> index 74d2a86..0db6545 100644
> --- a/net/can/j1939/Kconfig
> +++ b/net/can/j1939/Kconfig
> @@ -3,7 +3,7 @@
>  #
>  
>  config CAN_J1939
> -	tristate "SAE J1939"
> +	tristate "SAE J1939 (unstable API)"
>  	depends on CAN
>  	---help---
>  	  SAE J1939
> @@ -12,6 +12,7 @@ config CAN_J1939
>  	  The relevant parts in kernel are
>  	  SAE j1939-21 (datalink & transport protocol)
>  	  & SAE j1939-81 (network management).
> +	  Big fat warning: The API is yet unstable!
>  
>  config CAN_J1939_DEBUG
>  	bool "debug SAE J1939"
> 


-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Informations About CAN API of the Linux Kernel

[Kurt Van Dijck]

On Mon, Mar 11, 2013 at 04:10:12PM +0100, Marc Kleine-Budde wrote:
> On 03/11/2013 10:29 AM, Kurt Van Dijck wrote:
> > 
> > 
> > On Fri, Mar 08, 2013 at 01:51:23PM +0100, Robert Schwebel wrote:
> >> Hi Kurt,
> >>
> >> On Fri, Mar 08, 2013 at 11:05:48AM +0100, Kurt Van Dijck wrote:
> >>> Could I just mark j1939 as "EXPERIMENTAL" in Kconfig.
> >>> I think that is what I've seen most for 'unstable concepts'.
> >>
> >> EXPERIMENTAL is considered to be deprecated and might be removed from
> >> the kernel, so I wouldn't go down that road. Staging sounds right.
> > 
> > I see.
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle?id=v3.9-rc2#n549
> > 
> > Is such thing then appropriate?
> 
> Does j1939 have a protocol number? Probably.
Yes. 7.

> If so, we shouldn't use the
> "next free" one for an experimental protocol.
That's another reason to have J1939 merged.
I would have alerted anyhow when the protocol number 7 got allocated...

Kurt
> 
> Marc
> 
> > 
> > --
> > diff --git a/net/can/j1939/Kconfig b/net/can/j1939/Kconfig
> > index 74d2a86..0db6545 100644
> > --- a/net/can/j1939/Kconfig
> > +++ b/net/can/j1939/Kconfig
> > @@ -3,7 +3,7 @@
> >  #
> >  
> >  config CAN_J1939
> > -	tristate "SAE J1939"
> > +	tristate "SAE J1939 (unstable API)"
> >  	depends on CAN
> >  	---help---
> >  	  SAE J1939
> > @@ -12,6 +12,7 @@ config CAN_J1939
> >  	  The relevant parts in kernel are
> >  	  SAE j1939-21 (datalink & transport protocol)
> >  	  & SAE j1939-81 (network management).
> > +	  Big fat warning: The API is yet unstable!
> >  
> >  config CAN_J1939_DEBUG
> >  	bool "debug SAE J1939"
> > 
> 
> 
> -- 
> Pengutronix e.K.                  | Marc Kleine-Budde           |
> Industrial Linux Solutions        | Phone: +49-231-2826-924     |
> Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
> 



-- 
Kurt Van Dijck
GRAMMER EiA ELECTRONICS
http://www.eia.be
kurt.van.dijck@eia.be
+32-38708534

Re: Informations About CAN API of the Linux Kernel

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On 03/11/2013 04:34 PM, Kurt Van Dijck wrote:
> On Mon, Mar 11, 2013 at 04:10:12PM +0100, Marc Kleine-Budde wrote:
>> On 03/11/2013 10:29 AM, Kurt Van Dijck wrote:
>>>
>>>
>>> On Fri, Mar 08, 2013 at 01:51:23PM +0100, Robert Schwebel wrote:
>>>> Hi Kurt,
>>>>
>>>> On Fri, Mar 08, 2013 at 11:05:48AM +0100, Kurt Van Dijck wrote:
>>>>> Could I just mark j1939 as "EXPERIMENTAL" in Kconfig.
>>>>> I think that is what I've seen most for 'unstable concepts'.
>>>>
>>>> EXPERIMENTAL is considered to be deprecated and might be removed from
>>>> the kernel, so I wouldn't go down that road. Staging sounds right.
>>>
>>> I see.
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle?id=v3.9-rc2#n549
>>>
>>> Is such thing then appropriate?
>>
>> Does j1939 have a protocol number? Probably.
> Yes. 7.
> 
>> If so, we shouldn't use the
>> "next free" one for an experimental protocol.
> That's another reason to have J1939 merged.
> I would have alerted anyhow when the protocol number 7 got allocated...

Yes, but as soon as you are "officially" using the number 7, you have to
provide a stable API and ABI to the userspace.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Informations About CAN API of the Linux Kernel

[Oliver Hartkopp]

On 11.03.2013 17:00, Marc Kleine-Budde wrote:

> On 03/11/2013 04:34 PM, Kurt Van Dijck wrote:


>>> Does j1939 have a protocol number? Probably.
>> Yes. 7.
>>
>>> If so, we shouldn't use the
>>> "next free" one for an experimental protocol.
>> That's another reason to have J1939 merged.
>> I would have alerted anyhow when the protocol number 7 got allocated...
> 
> Yes, but as soon as you are "officially" using the number 7, you have to
> provide a stable API and ABI to the userspace.


Yep - Additionally i don't think, that reserving the "7" for CAN_J1939 is a
strong reason for pushing the merge process.

We (will say "the Linux CAN community") all know that J1939 is prepared by
Kurt and that we reserve the "7" proto number for it.

I personally see no reason that someone tries to allocate the "7" without our
joint acknowledge.

Regards,
Oliver