On Tue, Sep 28, 2021 at 09:31:45AM +0200, Daniel Vetter wrote: > On Sat, Sep 25, 2021 at 03:47:00PM +0200, Greg Kroah-Hartman wrote: > > In order to better track where in the kernel the dma-buf code is used, > > put the symbols in the namespace DMA_BUF and modify all users of the > > symbols to properly import the namespace to not break the build at the > > same time. > > > > Now the output of modinfo shows the use of these symbols, making it > > easier to watch for users over time: > > > > $ modinfo drivers/misc/fastrpc.ko | grep import > > import_ns: DMA_BUF > > > > Cc: Sumit Semwal <[email protected]> > > Cc: "Christian König" <[email protected]> > > Cc: Alex Deucher <[email protected]> > > Cc: "Pan, Xinhui" <[email protected]> > > Cc: David Airlie <[email protected]> > > Cc: Daniel Vetter <[email protected]> > > Cc: Maarten Lankhorst <[email protected]> > > Cc: Maxime Ripard <[email protected]> > > Cc: Thomas Zimmermann <[email protected]> > > Cc: Mauro Carvalho Chehab <[email protected]> > > Cc: Arnd Bergmann <[email protected]> > > Cc: [email protected] > > Signed-off-by: Greg Kroah-Hartman <[email protected]> > > --- > > > > The topic of dma-buf came up in the Maintainer's summit yesterday, and > > one comment was to put the symbols in their own module namespace, to > > make it easier to notice and track who was using them. This patch does > > so, and finds some "interesting" users of the api already in the tree. > > Yeah, the interesting ones is why I added the dma-buf wildcard match a > while ago. Since that landed I don't think anything escaped. Should we > perhaps also add > > K: MODULE_IMPORT_NS(DMA_BUF); > > to the dma-buf MAINATINERS entry? Entirely untested, also no idea whether > there's not a better way to match for module namespaces. Either way:
I think MAINTAINERS is already overloaded with too many of these things, but feel free to mess with it if you want to :) > Acked-by: Daniel Vetter <[email protected]> Thanks for the ack! greg k-h
