Sebastian Haas wrote: > Wolfgang, > > Wolfgang Grandegger schrieb: >> Hi Sebastian, > >> Sebastian Haas wrote: >>> Wolfgang, >> [snip] >>>>> 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. >>> At the moment net-next-2.6 holds stable and mainlined drivers, while SVN >>> holds _all_ mainlined and non-mainlained drivers. When we begin to work >>> against net-next-2.6 for new drivers and hope someone will port them >>> back to SVN, these two trees will drift away. >> This was not a real problem yet. > Not yet! How much drivers where developed against net-next-2.6? I only > know about the TI > HECC.
It's a option to backport the TI HECC driver to the SVN trunk. We will not do it as long as nobody asks for it. I'm willing to accept changes if they easy my maintenance work, which is already a lot of work. Moving the SVN repository to git would help, indeed, but only if we abandon the SVN repository as well. Otherwise it will just increase my workload. I'm going to trigger a thread on this subject later today, also on how we could better share the work load. >>>>>>> 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. >>> Everyone knows, the staging tree holds crap. Why not push our crap to >>> staging as well? Then we have only one repository/source where the >>> Socket CAN drivers for 2.6 are. >> Generally, we don't have crap in the SVN repository. It's not a big >> effort to update most of the drivers for kernel inclusion. But somebody >> with the hardware at hand must take care and do it. The staging tree is >> *not* for development. It serves a different purpose. For me, it's out >> of discussion. > Okay, crap was the wrong word. However, if it's out of discussion for > you, forget my proposal. My arguments didn't convince you? Well, then please ask the responsible people of the staging tree (or ask on the ML) if it would be acceptable to add our drivers for development therein. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
