On Mon, Sep 01, 2025 at 10:14:04AM +0200, Jan Beulich wrote:
> On 29.08.2025 21:27, Stefano Stabellini wrote:
> > On Thu, 28 Aug 2025, dmuk...@xen.org wrote:
> >> --- /dev/null
> >> +++ b/xen/common/emul/vuart/vuart.c
> >> @@ -0,0 +1,156 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only */
> >> +/*
> >> + * UART emulator framework.
> >> + *
> >> + * Copyright 2025 Ford Motor Company
> >> + */
> >> +
> >> +#include <xen/err.h>
> >> +#include <xen/sched.h>
> >> +#include <xen/vuart.h>
> >> +#include <xen/xvmalloc.h>
> >> +
> >> +#define for_each_emulator(e) \
> >> + for ( e = vuart_array_start; e < vuart_array_end; e++ )
> >> +
> >> +extern const struct vuart_emulator vuart_array_start[];
> >> +extern const struct vuart_emulator vuart_array_end[];
> >> +
> >> +static const struct vuart_emulator *
> >> +vuart_match_by_compatible(struct domain *d, const char *compat)
> >> +{
> >> + const struct vuart_emulator *emulator;
> >> +
> >> + if ( d->console.vuart )
> >> + return NULL;
> >> +
> >> + for_each_emulator(emulator)
> >> + if ( emulator->compatible &&
> >> + !strncmp(emulator->compatible, compat,
> >> + strlen(emulator->compatible)) )
> >
> > strncmp will continue until the given count even if compat is shorter
>
> Not really, one string having a nul char and the other not having one is a
> difference, at which point comparison will stop. There would be a problem
> if "compat" didn't point to a nul-terminated string, though (and I didn't
> check that aspect, not the least because then "shorter" doesn't really
> make much sense without a length passed in).
re: NUL-termination: current assumption is that both compat and
emulator->compatible are NUL-terminated.
Current `compat` comes from the hardcoded NUL-terminated string (vuart_info).
In case of `compat` is not NUL-terminated (I plan to populate the field from
xl in the future), strncmp() will stop after strlen(emulator->compatible)
bytes.
