| Message ID | 20231101093325.30302-19-jgross@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | tools: enable xenstore-stubdom to use 9pfs | expand |
Hi Juergen, On 01/11/2023 09:33, Juergen Gross wrote: > Rename the xenbus_evtchn() function to get_xenbus_evtchn() in order to > avoid two externally visible symbols with the same name when Xenstore- > stubdom is being built with a Mini-OS with CONFIG_XENBUS set. This works right now, but what guarantee us that Mini-OS will not change other symbols and clash with the one provided by Xenstored again? Furthermore, technically, this is a problem for all the other software linked with Mini-OS. So wouldn't it be better to modify the Mini-OS build system to prefix all the symbols of the linked binary (here Xenstored)? Cheers,
On 01.11.23 11:44, Julien Grall wrote: > Hi Juergen, > > On 01/11/2023 09:33, Juergen Gross wrote: >> Rename the xenbus_evtchn() function to get_xenbus_evtchn() in order to >> avoid two externally visible symbols with the same name when Xenstore- >> stubdom is being built with a Mini-OS with CONFIG_XENBUS set. > This works right now, but what guarantee us that Mini-OS will not change other > symbols and clash with the one provided by Xenstored again? > > Furthermore, technically, this is a problem for all the other software linked > with Mini-OS. So wouldn't it be better to modify the Mini-OS build system to > prefix all the symbols of the linked binary (here Xenstored)? How would that work? From Mini-OS point of view libraries are not distinguishable from the linked application. This would mean the build system would prefix the library symbols as well, while the application would try to reference the the un-prefixed library symbols. I think the only way to avoid this kind of problem would be to have a positive list of exported Mini-OS symbols and to hide all other symbols from linked libraries and the app. I can look into this, but I'd like to do this work outside of this series in order not to block its development for an unknown amount of time. Juergen
Hi Juergen, On 01/11/2023 11:08, Juergen Gross wrote: > On 01.11.23 11:44, Julien Grall wrote: >> Hi Juergen, >> >> On 01/11/2023 09:33, Juergen Gross wrote: >>> Rename the xenbus_evtchn() function to get_xenbus_evtchn() in order to >>> avoid two externally visible symbols with the same name when Xenstore- >>> stubdom is being built with a Mini-OS with CONFIG_XENBUS set. >> This works right now, but what guarantee us that Mini-OS will not >> change other symbols and clash with the one provided by Xenstored again? >> >> Furthermore, technically, this is a problem for all the other software >> linked with Mini-OS. So wouldn't it be better to modify the Mini-OS >> build system to prefix all the symbols of the linked binary (here >> Xenstored)? > > How would that work? > > From Mini-OS point of view libraries are not distinguishable from the > linked application. This would mean the build system would prefix the > library symbols as well, while the application would try to reference > the the un-prefixed library symbols. AFAICT, objcopy could rename symbols. So if you pre-process the libraries and application before hand, then you should still be able to link. > > I think the only way to avoid this kind of problem would be to have a > positive list of exported Mini-OS symbols and to hide all other symbols > from linked libraries and the app. > > I can look into this, but I'd like to do this work outside of this > series in order not to block its development for an unknown amount of > time. I am ok with that: Reviewed-by: Julien Grall <jgrall@amazon.com> Cheers,
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h index ad87199042..480b0f5f7b 100644 --- a/tools/xenstored/core.h +++ b/tools/xenstored/core.h @@ -383,7 +383,7 @@ static inline bool domain_is_unprivileged(const struct connection *conn) } /* Return the event channel used by xenbus. */ -evtchn_port_t xenbus_evtchn(void); +evtchn_port_t get_xenbus_evtchn(void); /* Write out the pidfile */ void write_pidfile(const char *pidfile); diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c index 409b53acf9..6ef136e01f 100644 --- a/tools/xenstored/domain.c +++ b/tools/xenstored/domain.c @@ -1208,7 +1208,7 @@ void dom0_init(void) evtchn_port_t port; struct domain *dom0; - port = xenbus_evtchn(); + port = get_xenbus_evtchn(); if (port == -1) barf_perror("Failed to initialize dom0 port"); diff --git a/tools/xenstored/minios.c b/tools/xenstored/minios.c index b5c3a205e6..0779efbf91 100644 --- a/tools/xenstored/minios.c +++ b/tools/xenstored/minios.c @@ -38,7 +38,7 @@ void init_pipe(int reopen_log_pipe[2]) reopen_log_pipe[1] = -1; } -evtchn_port_t xenbus_evtchn(void) +evtchn_port_t get_xenbus_evtchn(void) { return dom0_event; } diff --git a/tools/xenstored/posix.c b/tools/xenstored/posix.c index 6ac45fdb45..7e03dd982d 100644 --- a/tools/xenstored/posix.c +++ b/tools/xenstored/posix.c @@ -111,7 +111,7 @@ void unmap_xenbus(void *interface) munmap(interface, getpagesize()); } -evtchn_port_t xenbus_evtchn(void) +evtchn_port_t get_xenbus_evtchn(void) { int fd; int rc;
Rename the xenbus_evtchn() function to get_xenbus_evtchn() in order to avoid two externally visible symbols with the same name when Xenstore- stubdom is being built with a Mini-OS with CONFIG_XENBUS set. Signed-off-by: Juergen Gross <jgross@suse.com> --- tools/xenstored/core.h | 2 +- tools/xenstored/domain.c | 2 +- tools/xenstored/minios.c | 2 +- tools/xenstored/posix.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)