[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3] xen/console: print Xen version via keyhandler
On 13.02.2025 22:41, dmkhn@xxxxxxxxx wrote: > Add Xen version printout to 'h' keyhandler output. > > That is useful for debugging systems that have been left intact for a long > time. > > Signed-off-by: Denis Mukhin <dmukhin@xxxxxxxx> > --- > Changes since v2: > - moved new function declarations to xen/lib.h > - dropped xen_ prefix in new functions > --- > xen/common/keyhandler.c | 4 ++++ > xen/common/version.c | 20 ++++++++++++++++++-- > xen/drivers/char/console.c | 8 +++----- > xen/include/xen/lib.h | 3 +++ > 4 files changed, 28 insertions(+), 7 deletions(-) > > diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c > index 6ea54838d4..0bb842ec00 100644 > --- a/xen/common/keyhandler.c > +++ b/xen/common/keyhandler.c > @@ -129,6 +129,10 @@ static void cf_check show_handlers(unsigned char key) > unsigned int i; > > printk("'%c' pressed -> showing installed handlers\n", key); > + > + print_version(); > + print_build_id(); > + > for ( i = 0; i < ARRAY_SIZE(key_table); i++ ) > if ( key_table[i].fn ) > printk(" key '%c' (ascii '%02x') => %s\n", > diff --git a/xen/common/version.c b/xen/common/version.c > index bc3714b45f..8672d5544e 100644 > --- a/xen/common/version.c > +++ b/xen/common/version.c > @@ -210,9 +210,25 @@ void __init xen_build_init(void) > } > } > #endif /* CONFIG_X86 */ > - if ( !rc ) > - printk(XENLOG_INFO "build-id: %*phN\n", build_id_len, build_id_p); > } > + > +void print_version(void) > +{ > + printk("Xen version %d.%d%s (%s@%s) (%s) %s %s\n", > + xen_major_version(), xen_minor_version(), xen_extra_version(), > + xen_compile_by(), xen_compile_domain(), xen_compiler(), > + xen_build_info(), xen_compile_date()); > + > + printk("Latest ChangeSet: %s\n", xen_changeset()); > +} > + > +void print_build_id(void) > +{ > + BUG_ON(!build_id_p); > + BUG_ON(!build_id_len); Technically one of the two would likely suffice, if we need such checks at all. Question is why you added them. After all ... > + printk(XENLOG_INFO "build-id: %*phN\n", build_id_len, build_id_p); ... this isn't supposed to malfunction when passed a NULL pointer (with zero length). If it can malfunction, it wants fixing there imo. And that extends to the case of non-zero length as well: Any extensions to %p that we add would better retain the basic property of %p printing when NULL is passed as argument. (I'm sorry for not paying enough attention to this on v2 already.) (Later) Oh, actually these BUG_ON() are both wrong. They would trigger when building with a build-id-incapable linker. See the detection logic in the top level Makefile (search for XEN_HAS_BUILD_ID). To retain original behavior you will want to make the printk() conditional upon e.g. build_id_len being non-zero. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |