On Tue, Oct 17, 2023 at 04:20:22PM +0100, Joao Martins wrote: > On 17/10/2023 13:58, Jason Gunthorpe wrote: > > On Mon, Oct 16, 2023 at 07:50:25PM +0100, Joao Martins wrote: > >> On 16/10/2023 19:37, Joao Martins wrote: > >>> On 16/10/2023 19:20, Jason Gunthorpe wrote: > >>>> On Mon, Oct 16, 2023 at 07:15:10PM +0100, Joao Martins wrote: > >>>> > >>>>> Here's a diff, naturally AMD/Intel kconfigs would get a select IOMMUFD_DRIVER as > >>>>> well later in the series > >>>> > >>>> It looks OK, the IS_ENABLES are probably overkill once you have > >>>> changed the .h file, just saves a few code bytes, not sure we care? > >>> > >>> I can remove them > >> > >> Additionally, I don't think I can use the symbol namespace for IOMMUFD, as > >> iova-bitmap can be build builtin with a module iommufd, otherwise we get into > >> errors like this: > >> > >> ERROR: modpost: module iommufd uses symbol iova_bitmap_for_each from namespace > >> IOMMUFD, but does not import it. > >> ERROR: modpost: module iommufd uses symbol iova_bitmap_free from namespace > >> IOMMUFD, but does not import it. > >> ERROR: modpost: module iommufd uses symbol iova_bitmap_alloc from namespace > >> IOMMUFD, but does not import it. > > > > You cannot self-import the namespace? I'm not that familiar with this stuff > > Neither do I. But self-importing looks to work. An alternative is to have an > alternative namespace (e.g. IOMMUFD_DRIVER) in similar fashion to IOMMUFD_INTERNAL. > > But I fear this patch is already doing too much at the late stage. Are you keen > on getting this moved with namespaces right now, or it can be a post-merge cleanup? It is our standard, if you want to make two patches in this series that is OK too Jason
