RE: Linux J1939: built in-kernel vs. user space stack?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

Thank you for your clarifying answers.

It appears I have made too many assumptions about the load distribution: like J1939 configuring the CAN layer as such that the major load is handled by CAN, while J1939's job can be limited to interpreting only relevant incoming data. Sorry for that.
--> I will dive into the implementation details and probably level up about the J1939 protocol too.
Our goal is to build J1939 modules, dedicated to a single task. Some examples: displaying certain parameters, logging J1939 traffic on a line, injecting (faulty) messages for testing purposes.

So I will now familiarize better with the linux-can world and have a look at eclipse titan. Only then I will be able to have a well-founded answer to your reactions.

Best regards,
Kristoff

-----Oorspronkelijk bericht-----
Van: Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> 
Verzonden: woensdag 26 juni 2019 10:25
Aan: David Jander <david@xxxxxxxxxxx>
CC: linux-can <linux-can@xxxxxxxxxxxxxxx>; AVERMAETE Kristoff <kristoff.avermaete@xxxxxxxxxxx>; Kurt Van Dijck <dev.kurt@xxxxxxxxxxxxxxxxxxxxxx>; Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx>
Onderwerp: Re: Linux J1939: built in-kernel vs. user space stack?

On 6/26/19 10:13 AM, David Jander wrote:
>> Do you think it would be an interesting contribution if I isolated 
>> the functionality in user space?
>> That way we could test our application code along with the isolated
>> J1939 stack on whatever CAN-enabled Linux platform is provided to us.
>>
>> Do you think this is a bad idea?
> 
> With "isolating" the functionality in user-space, you mean having a 
> separate user-space J1939 stack that can be used for testing the kernel-stack?
> That would actually be a great idea.
> 
> There is J1939 support in the can-utils already:
> 
> https://github.com/linux-can/can-utils
> 
> But a full-blown alternative implementation that can be used for 
> regression-testing may be nice to have of course, if it can be GPL'ed

An _alternative_ implementation of a j1939 stack (especially when it comes to (E)TP) for testing would be nice to have. This is where eclipse titan comes into the game. However from my point of view it makes no sense to port the in-kernel stack to user space.

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   |


DISCLAIMER:

Any email committing our company needs to be approved by the managing
director. This email and its attachments are for the intended addressee only. If 
you have received it in error then please delete it and notify the sender by return 
email. In case of doubt about correctness or completeness of this email please 
contact the sender. Thank you for your cooperation.
Warning: Any mail sent to this e-mail address is considered as company mail and can be opened by the Management.
Van Hool conditions are applicable and this without reservation on all offers, sales, purchases,…




[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux