![]() | |||||||||||||
Messages in this thread |
> > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 14:08 [from the cache] ©2003-2008 | |||||||||||||