> >> > >> You can't really publish those headers sanely, and part of the point > >> here was specifically to allow using things like statomic.h properly > >> without having to be concerned about how to install the shim into a > >> public header. > >> > >> In my view, the best approach, which I have suggested before, is to > >> build the out-of-tree stuff 'in-tree' and discard everything except > >> the single provider library you are building for. For instance, a rpm > >> spec file that produces as contents a single provider shlib. > >> > >> This seems like the least amount of work for everyone, and it doesn't > >> really matter, I think, that the 'source' for the 'provider' carries > >> lots of unbuilt stuff. > >> > >> Perhaps the best way to accomplish that is to add a sample rpm spec > >> file to Documentation/ or something that shows how to do that. If you > >> want to take a first stab at it I can give you some help. > > Hey Jason, Thanks for this detailed response! I appreciate it. > > > > Today I did two experiments: > > > > 1) I took my out-of-tree provider, and moved it into rdma-core, updated it to > > use the rdma-core bldenv and APIs. This included the rdma-core mmio and > > dma/cache services, plus a few other nits like ccan, and the new byte swapping > > API, and got it building. That was pretty straight forward. > > > > 2) I took the updated out-of-tree provider src from 1), and put it back in the > > out-of-tree provider automake/config bldenv, and then tried to pull in whatever > > was needed from rdma-core to build it. This resulted in me pulling certain > > files, like you mentioned above. I just pulled them from the rdma-core/build/ > > tree for the sake of getting it to build. Basically I needed ccan/* > > infiniband/driver.h, and util/compiler.h/udma_barrier.h. That got it to build. > > > > > > I haven't tested either of these yet to see if they actually load. But that's > > where I'm at. #2 has the issues you describe, in that the atomic header is > > auto-generated based on the installed distro/platform. So that leads to using > > #1 which is what you recommend. > Hi, > > I 'm not sure I see the issue here (or at least nothing easily fixed). > If the standard spec produces an extra rdma-core-provider-devel with those > headers, it's just a matter of rebuilding the out-of-tree provider against the right > distro/package. > After thinking about this more, I agree: If rdma-core is built into binary platform and distro-specific rpms, then these header files are definitely available to export as a -devel rpm for that same platform/distro. Jason, am I missing something? Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
