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

Re: RFS: socketcan-utils

On 31.05.2011 09:46, Markus Becker wrote:
>> On 30.05.2011 09:16, Markus Becker wrote:
>>> Well, we explicitly need isotp, which is not included in stock debian
>>> images. That's actually the reason for creating the images. Any idea of
>>> how to get Linux mainline isotp kernel module into the Debian kernel?
>> My problem is, that we're using my isotp stuff for many purposes for more
>> than two years now. I'm not far from sending a patch on netdev-ML - but
>> i'm still missing some feedback from isotp-users (like you), if they think
>> the protocol and it's API are mature enough for mainline ... is it?
> Within the next two month, we will test two telematic devices against 
> socketCAN ISO-TP and raw or J1939 frames. The Debian packages were created to 
> get our test equipment ready. Will report to you on our experience.

Thanks! You are also working with j1939 ?? Did you check out the work of Kurt
van Dijck in socketcan/branches/j1939?

> If sent now upstream, this would possibly end up in 3.0.1 or whatever number 
> the first kernel after 3.0.0 would have, or would it be 3.0.2? Then I could get 
> rid of the socketcan-driver package again, or the J1939 would be included 
> then...

If so, it would get into 3.1

>>> Of course one needs to rmmod all CAN kernel modules and load the 
> appropriate 
>>> svn ones.
>>> I would prefer to put an explicit warning into the package description.
>> Better we get isotp into mainline :-)
> Until then, I think I should clarify this in the package description. E.g. 
> some text like this:
> WARNING: This package contains experimental kernel modules that might conflict 
> with the mainline kernel modules. You are required to unload all provided CAN 
> modules, before using the kernel modules that are created from this package. 
> If you do not intend to use ISO-TP or J1939 kernel modules, you do not need 
> this package.

Ugh, that's hard stuff. I don't think it's a good idea to provide 'pre
release' protocol implementations & APIs, people build their application on.

It's not only the mix of modules but the release of an API in discussion. Of
course you can build a debian socketcan-modules for your own purposes, but
having this on a 'real' debian repo doesn't look like a good idea.


Reply to: