linux-kernel - Re: 2.6.18 Headers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <6C943713-549B-453C-A0B2-1286764FFE13@mac.com>
Date:	Sun, 16 Jul 2006 08:34:53 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Albert Cahalan <acahalan@...il.com>
Cc:	dwmw2@...radead.org, arjan@...radead.org, maillist@...55.com,
	ralf@...ux-mips.org, linux-kernel@...r.kernel.org,
	davem@...emloft.net
Subject: Re: 2.6.18 Headers - Long

On Jul 15, 2006, at 17:09:28, Albert Cahalan wrote:
> Here we have a full-featured set of atomic ops,

You realize that on a couple architectures it's fundamentally  
impossible to get atomic ops completely in userspace, right?  Some of  
the mechanisms that various archs use (IIRC including in one or two  
cases just completely disabling interrupts) don't work anywhere but  
the kernel.

> byte swapping with readable names and a distinction for pointers,  
> nice macros for efficient data structure manipulation...

Both of which may be easily cut and pasted into your GPL programs  
with little or no effort (Hint: I do this all the time).  Those are  
so stable you don't even have to maintain it!  IMHO, what you really  
want, though, is for GCC to export a library of ASM intrinsics (like  
memory barriers, atomic ops, etc), that are available on your current  
architecture.  If there is no __gcc_atomic_inc then it wouldn't  
#define it and you can just go back to pthread_mutex_lock/unlock for  
protecting an atomic variable.  Such a library layer certainly  
doesn't belong in the kernel, although if GCC got such a library  
right the kernel might start to use it (although only the most recent  
GCC would support it so it wouldn't be very useful).

> Sure, you'd like all the app developers to [...] use sucky POSIX  
> threads stuff

There is *NO* portable way to get atomic operations or locking in  
userspace except through libpthread.  Atomic operations in the kernel  
are sometimes _not_ atomic in userspace and the only decent way to do  
userspace locking is to call into the kernel on contention (or you  
waste the rest of your timeslice spinning).  POSIX thread operations  
are extremely efficient under Linux, but the kernel shouldn't export  
the varying underlying operations.

Cheers,
Kyle Moffett

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