Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

From: Arjan van de Ven
Date: Sun Nov 28 2004 - 07:21:51 EST



> > The problem with these (atomic.h
> >
> > that is a very non portable header and there are several good
> > alternatives (see the apr library for example). In fact. atomic.h is
> > *dangerous* in userspace, it is only atomic if CONFIG_SMP is set, so if
> > you compile your app on a machine without that set and then run it on an
> > smp machine, you are not atomic.
>
> Yes, it appears that most people who attempted to use this
> have already been bitten so hard that they stopped trying.

and for people who'd be tempted for new code it should at least warn if
not error even right now


> > > , byteorder.h,
> >
> > there are perfectly good alternatives in glibc
>
> Google found abuses of byteorder.h in kdeedu, dbootstrap and netatalk,
> I would expect to find many more if I kept looking.

it's still very much abuse, and quite nasty for dual endian platforms ;)

> > > , spinlock.h
> >
> > EHHHH????? Spinlocks in userland? You got to be kidding.
>
> I don't think it's that uncommon to use spinlocks in user
> space, IIRC samba (tdb) and some databases implement their
> own version of user spinlocks.

implementing your own is still evil, but glibc provides similar
constructs already. busy waiting in userspace is evil anyway (use futex
:) and.... just as with atomic.h, spinlock.h only gets compiled in for
CONFIG_SMP so the same caveats apply

> The kernel implementation
> is used at least in "Open Runtime Platform" and in "Chrony".
> Chrony even has an FAQ entry on how to circumvent the
> "#ifndef __KERNEL__" that was added in Red Hat Linux...

Chrony then needs to make their own (by copying and cleaning up for all
I care).



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/