asm-generic/unistd.h and glibc use of NR_ipc

[Mike Frysinger]

On Tuesday, September 28, 2010 09:05:13 Chris Metcalf wrote:
> On 9/28/2010 4:40 AM, Arnd Bergmann wrote:
> > Chris Metcalf is using the generic unistd.h file on the tile architecture
> > and has a glibc port that should be easily portable to all future
> > architectures. There are a few of them getting ready to be merged
> > now (c6x, lm32, nios2, and some people have contacted me privately
> > for architectures I cannot name).

c6x lacks a MMU, so i dont see how it could possibly use glibc.  same for 
lm32.  nios2 at least has an optional MMU, so it'd be usable some of the time.  
so no, i dont see a generic unistd.h glibc port being useful for them.

> One question for the libc folks is nomenclature.  For now I'm using
> "sysdeps/unix/sysv/linux/generic" to hold the sources that are meant to be
> used for any architecture that uses Arnd's <asm-generic/unistd.h> along
> with the other asm-generic headers, e.g. <asm-generic/stat.h>.   I've
> appended a list of the files that I've put in that directory to this
> email.  Many of them are there just for handling missing "standard"
> syscalls in <asm-generic/unistd.h>; for example the "readlink" syscall
> becomes "readlinkat" in dl-origin.c, etc.
> 
> Is this the best name to use for the directory, though?  In particular,
> glibc already uses "sysdeps/generic" in a slightly special sense to provide
> the fallback if no sysdeps override is available for a given file.  But the
> Linux naming of "generic unistd.h" is pretty commonplace, so I assume that
> in the "linux/" hierarchy it is reasonably clear what that subdirectory
> means.

i think "generic" in the context of "linux" is ok, but about the only real 
answer you'd get is if it comes from drepper/roland.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20100928/2402d8d4/attachment.sig>