Sebastian Haas wrote: > Wolfgang, > > Wolfgang Grandegger schrieb: >> Sebastian Haas wrote: >>> Oliver Hartkopp schrieb: >> [snip] >>> So we have the benefits to have a local repository were the developer can >>> work on >>> and creating and submitting patches becomes easier. Would be fine. >>> >>>> For me the current process could be: >>>> * For new drivers (like ems_usb.c): >>>> 1. Post source as a diff to net-next-2.6 on SocketCAN Core ML >>>> 2. Make some reviews. Still needed changes: goto 1 >>>> 3. Post source as a diff to net-next-2.6 on netdev ML >>>> 4. Make some reviews. Still needed changes: goto 1 or 3 >>>> 5. Acked-by: Wolfgang >>>> 6. Done Mainlining >>>> 7. Apply source to out-of-tree-repository >>>> 8. Add backward compatibility stuff >>>> 9. Done >>> I don't like 8. This sounds simple for a simple network driver, but becomes >>> un- >>> maintainable for complex drivers like an USB device driver or PCMCIA board. >> Almost nobody is working with the bleeding edge kernel and there is some >> real benefit for the users providing backward compatibility. This does >> not mean that we spend time for providing support for very old kernels, >> at least not without real demand. Oliver introduced: > >> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22) >> #error This driver does not support Kernel versions < 2.6.22 >> #endif > >> which makes clear what kernel versions are supported. > Okay, but I can't invest effort in supporting older kernel than my system is > running on.
Nobody ask you for. > > Is there any general requirement/rule which kernel version a driver have > to support? No. It can start with 2.6.31, no problem. >>>> Looks the described process sane to all of you? >>> Let summarize: >>> Work on already mainlined drivers or new drivers is done on net-next-2.6. >>> Not yet >>> mainlined drivers becomes ready for mainlining in the out-of-tree >>> repository which >>> we move to GIT. >> In principle yes, but it's not a real requirement that the driver must >> first be for the SVN trunk. Patches directly for net-next-2.6 are >> accepted as well, of course, if they are OK. See the ti_hecc driver >> posted recently. When it gets accepted, it's not a big deal to adapt it >> for the out-of-tree SVN code. > Who does this adaption? The minimal code adaption is just: s+linux/can+socketcan/can+ plus some extra lines for the build environment (Makefile). Depending of the kernel versions supported, there might be more, like using the ND2D() macro, handling netdev stats, etc. >>> There is another option (just a thought worth). The staging-tree is >>> indented for >>> drivers which are not yet ready for kernel inclusion. This criteria matches >>> for all >>> currently not yet mainlined drivers. Why not moving them to the staging >>> tree so >>> we have all drivers in net-next-2.6? This would also increase the audience >>> of kernel >>> developers which may take look at this drivers to help us, getting them out >>> of staging? >> Honestly, it's a *waste* time and I also do not want that pre-mature and >> buggy drivers enter the mainline kernel. I'm really surprised that it's >> possible at all. > It's just your opinion. I don't want to start an ideology debate about > pro and cons of the staging driver. It's just an option. That's my personal opinion, of course. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
