[PATCH 02/13] alist: Allow inclusion from OS headers

[Tom Rini]

On Wed, May 27, 2026 at 08:36:45PM +0200, Heinrich Schuchardt wrote:
> On 5/27/26 18:10, Simon Glass wrote:
> > Sandbox needs to include system headers in some files, but also wants
> > to use alist. Adjust the headers to permit this.
> > 
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> > 
> >   include/alist.h | 16 +++++++++++-----
> >   lib/alist.c     |  1 +
> >   2 files changed, 12 insertions(+), 5 deletions(-)
> > 
> > diff --git a/include/alist.h b/include/alist.h
> > index b00d9ea97d6..69d7cdb722f 100644
> > --- a/include/alist.h
> > +++ b/include/alist.h
> > @@ -10,8 +10,14 @@
> >   #define __ALIST_H
> >   #include <stdbool.h>
> > -#include <linux/bitops.h>
> > +
> > +#ifdef USE_HOSTCC
> > +#include <sys/types.h>
> > +#include <stdint.h>
> > +#else
> >   #include <linux/types.h>
> > +#endif
> > +#define BIT(nr)			(1UL << (nr))
> 
> BIT(nr) is already defined in include/linux/bitops.h.
> 
> We must not assume that no module includes both alist.h and linux/bitops.h.
> E.g. include/expo.h and include/lmb.h include both alist.h and
> linux/bitops.h. We should avoid redefinitions.
> 
> The following is an abuse of the enum type:
> 
> enum alist_flags {
>         ALISTF_FAIL     = BIT(0),
> };
> 
> As this is the only use of BIT(), we could simply use the value "1" here.
> 
> #define ALISTF_FAIL (1)
> 
> But as ALISTF_FAIL is the only bit in flags used, the best solution would be
> replacing flags by a boolean called fail.

I see this as another reminder about how frustrating it was that alist
was introduced under the guise of "must have this for an x86 feature"
but instead is a solution in need of a problem to solve, and whenever
it's used for something else, yet another problem with it is shown.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260527/d0cc9767/attachment.sig>