> 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?
Not yet, but wanted to test it. > > 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. Well, OK, then I will keep socketcan-drivers private, so that we can easily install them (until they are in mainline kernel) and only push socketcan-utils for inclusion. If/when a sponsor is interested. Markus > Regards, > Oliver ------------------------------------------------ | Dipl.-Ing. Markus Becker | Communication Networks | TZI - Center for Computing Technologies | University Bremen | Germany ------------------------------------------------ | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: [email protected] | telephone: +49 421 218 62379 | building: NW1 room: N2260 ------------------------------------------------ _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
