On Mon, Apr 20, 2015 at 10:47 AM, Ben Pfaff <[email protected]> wrote: > On Mon, Apr 20, 2015 at 10:07:54AM -0700, Alex Wang wrote: >> On Mon, Apr 20, 2015 at 1:17 AM, Thomas Graf <[email protected]> >> wrote: >> >> > On 04/19/15 at 10:15pm, Alex Wang wrote: >> > > With the latest change of separating vports into their own modules, >> > > it is necessary to export all public functions in linux/compat/linux/. >> > > This will prevent the linker error when vport modules use those >> > > functions in the future. e.g., the to be merged vport-stt module will >> > > use the flex_array_* functions which are not currently exported. >> > > >> > > Signed-off-by: Alex Wang <[email protected]> >> > >> > I wanted to avoid exporting all symbols if possible. We basically >> > need to add rpl defines for most of them if we want to do so. >> >> Could you explain more? My understanding is that even we rpl define them >> we still need to export the symbol if the function is used in a vport-* >> module. >> Unless we all inline them. > > I can't speak for Thomas, but I'm nervous about exporting all of these > under their normal kernel names. I wouldn't want some other > third-party module to somehow pick them up as if they were full and > correct implementations of the functions they name: sometimes our > replacements are only partial implementations, that are good enough > for our purposes but maybe not for others'.
When I talked with Alex previously, I think the plan was that we would prefix all exported symbols with rpl_. We would then have a check to ensure that all public functions are exported (the one he sent out in patch 2 of this series) and then another check to ensure that all exported symbols in the compat directory are prefixed with rpl_. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
