-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Is there any general requirement/rule which kernel version a driver have to support? >>> 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? >> 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. Cheers, Sebastian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqvTaQACgkQpqRB8PJG7XysVgCglsBQeYQX/PiHgg1hYrtilPRR EnkAoIaF9W4NUITwCKS/wbj42Z9HZZ8A =robo -----END PGP SIGNATURE----- -- EMS Dr. Thomas Wuensche e.K. Sonnenhang 3 85304 Ilmmuenster HRA Neuburg a.d. Donau, HR-Nr. 70.106 Phone: +49-8441-490260 Fax : +49-8441-81860 http://www.ems-wuensche.com _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
