On Thu, Dec 01, 2016 at 07:26:09AM -0800, Christoph Hellwig wrote: > On Thu, Dec 01, 2016 at 10:20:39AM -0500, Don Zickus wrote: > > > > - provide the memory allocation (instead of having the driver staticly > > allocate) > > - provide functions to retrieve various internal data (instead of having the > > driver do direct referencing to deep internal elements) > > - cut down on some static inlines (and use accessory functions instead), > > etc. > > > > Those types of changes allow the OOT driver to be more ignorant of kernel > > changes and struct modifications. > > All that is counter to what we really want to have: a well integrated > kernel that moves forward together so that we can see and improve the > whole situation. No need to make things worse just to help leeches. > Get your damn drivers upstream ASAP and let's stop this discussion.. I understand and won't disagree with you. :-) Unfortunately, there are various drivers that will never go upstream - paid storage drivers that provide bells and whistles on top of inbox driver - old drivers/fs that application has been relying on for a long time but company doesn't have resources to migrate to current technology. We have been trying over the years to do what we can to move customers in the right direction. It is just a slow process, sadly. Cheers, Don -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
