On 08/15/2017 12:54 AM, Linus Walleij wrote: > On Sat, Aug 12, 2017 at 1:20 AM, Dave Jiang <dave.jiang@xxxxxxxxx> wrote: > >> There are no in kernel consumers for DMA_SG op. Removing operation, >> dead code, and test code in dmatest. >> >> Signed-off-by: Dave Jiang <dave.jiang@xxxxxxxxx> >> Cc: Gary Hook <gary.hook@xxxxxxx> >> Cc: Ludovic Desroches <ludovic.desroches@xxxxxxxxxxxxx> >> Cc: Kedareswara rao Appana <appana.durga.rao@xxxxxxxxxx> >> Cc: Li Yang <leoyang.li@xxxxxxx> >> Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> >> Cc: Michal Simek <michal.simek@xxxxxxxxxx> > > It seems to be too much code to carry on without any active > in-kernel users, so: > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> Thanks Linus! > >> Even if it is used by somebody, the code is out of tree and thus >> unsupported. Unless they upstream their code and utilize DMA_SG, the >> burden is on them to maintain whatever support they need. Linux kernel >> does not maintain dead code. > > This is no "hard" rule, we use common sense. If we see a compelling > argument to carry some code (like it is infrastructure for WIP stuff) we > do listen to reason. But yeah, dead code is pointless. > >> I have quite a bit of "extra" code in >> ioatdma that would make my life easier if it's upstream and used by >> third parties. However I can't because upstream does not take code with >> no in kernel consumer. So I continue to support them out of tree. > > TBH I think we carry quite a bit of such code it'd just that the > process of acceptance is far from perfect so there is no gatekeeper > in many cases. > >> The >> DMA_SG code really shouldn't have been accepted into the kernel in the >> first place. > > As Ira explained this code did have in-kernel users for a while. > Actually the sequence will be: > > - DMA_SG was accepted > - Kernel internal user was added > - Kernel internal user was removed > - DMA_SG was removed > > Yours, > Linus Walleij > -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
