On 11/01/2015 01:06 PM, Greg Kroah-Hartman wrote: > On Sun, Nov 01, 2015 at 02:10:48PM +0200, Or Gerlitz wrote: >> On 10/29/2015 1:51 PM, Christoph Hellwig wrote: >>> On Wed, Oct 28, 2015 at 10:57:59PM -0400, Doug Ledford wrote: >>>>>>> I had to do a minor hand merge to get this to apply, but it has been >>>>>>> pulled in for 4.4. >>>>> >>>>> This breaks all of the drivers in staging BTW. That will need fixed up >>>>> before the pull request goes in during the merge window. >>> That latest branch on infradead.org should have fixed all the staging >>> drivers. But Linus just clarified that we indeed do not have to care for >>> staging drivers, I asked him at kernel summit in front of the whole audience. >> >> Can you and/or Greg clarify this a little further... when someone modified >> an API called by others >> drivers, they don't have to deal with staging drivers? > > Yes, that is correct. > >> that is, the folks that care for this staging code need to handle >> that? > > Yes, that is correct. > > It's up to the owners of the staging drivers to do the work, we do not > make it the responsibility of anyone else. Now most of the time people > are nice and fix up everything else, but it's not a requirement at all. > > hope this helps, Not really. That may be a satisfactory answer for most of the things in the staging area, but it is not a satisfactory for the items I moved into that area. The things I moved there belong in one of two categories: 1) Aging, but working, drivers that will be removed in the future. Since we no longer have a deprecation mechanism, I was informed that the normal procedure now is to move the driver to staging for a while and then remove it permanently on a future schedule. This provides an orderly removal process. But, if you make it so that random people can break the driver with no responsibility for fixing up their breakage, in contrast to the entire rest of the kernel, then you eliminate that orderly removal process and turn it into a completely non-deterministic and chaotic removal process. So, no, if that's how it will be handled, I will move the deprecated drivers back to the main rdma tree and time them out and perform the orderly removal myself. 2) New drivers (one currently, one other one submitted but not yet pulled in) under active development but which need specific things fixed up. These have people already working on them full time. They were submitted to the staging tree with a specific TODO in order to get out. If you then break that driver and force the driver author to fix it, you have in essence changed the TODO list. That means you now have a moving goal post scenario. And this behavior is somewhat justified if you have a driver that is languishing in staging and being mostly ignored by the authors/maintainers of the driver. If the maintainers don't care enough about it to fix it up, why should the core kernel developers keeping the kernel modern fix them up? But what about when the drivers *are* being actively maintained and worked on? From the perspective of a maintainer trying to get their driver out of staging, this policy means that drivers that are already in the main tree get help from the core developer who *must* fix them up to work with their changes according to policy, while the same core developer is allowed to ignore any responsibility for fixing up any staging drivers. At the same time, it is highly likely that since the core kernel drivers have reached a level of maturity that they don't really *need* a lot of help keeping up with changes nor require a lot of work. The maintainer trying to get their driver out of staging however could probably use the help the most, and certainly likely doesn't need any extra work dumped on their back. So, no, for the drivers I have moved into the staging tree, I don't support this policy. This policy is really just a means of not making core developers work on drivers that no one cares about. The *means* of saving those core developers that work turns out to effectively be a punishment to any driver maintainer in the staging area who isn't allowing their driver to languish and go unmaintained. Because the staging tree is not limited to just drivers deserving of this punishment, the policy itself is inappropriate IMO. If that's going to be a problem, I have no issue moving the entire staging/rdma tree back into the drivers/infiniband area and fixing it up appropriately. -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature