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

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

[Linas Vepstas]

I'm trying to figure out the status of glibc w.r.t the latest linux
unistd syscall interface, specifically, the status of the NR_ipc
syscall.   Currently, I see the following:

-- Circa June 2009, Arnd Bergman introduced asm-generic/unistd.h
(into the linux kernel) to provide a generic interface to system
calls. It does *not* define NR_ipc, and instead provides
NR_msgsnd, msgrcv, msgget, msgctl etc. syscalls.

-- Current glibc (2.12.1, as well as the current eglibc) does
not appear to use these new calls anywhere. Instead, glibc
has generic (non-arch-specific) implementations of msgsnd
etc.  that use the old NR_ipc interface (see, e.g.
sysdeps/unix/sysv/linux/msgsnd.c, semget.c, shmdt.c, msgrcv.c,
shmget.c, etc.)

Is someone working on patches to get glibc to use the new
syscall interfaces (for IPC)?  Am I missing something? Seems like
any arch wishing to use asm-generic/unistd.h and get glibc working
gets to break new ground, here ... right?

-- Linas

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 417 bytes --]

On Monday, September 27, 2010 19:26:29 Linas Vepstas wrote:
> -- Current glibc (2.12.1, as well as the current eglibc) does
> not appear to use these new calls anywhere. Instead, glibc
> has generic (non-arch-specific) implementations of msgsnd
> etc.  that use the old NR_ipc interface (see, e.g.
> sysdeps/unix/sysv/linux/msgsnd.c, semget.c, shmdt.c, msgrcv.c,
> shmget.c, etc.)

did you miss syscalls.list ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arnd Bergmann]

On Tuesday 28 September 2010, Linas Vepstas wrote:
> I'm trying to figure out the status of glibc w.r.t the latest linux
> unistd syscall interface, specifically, the status of the NR_ipc
> syscall.   Currently, I see the following:
> 
> -- Circa June 2009, Arnd Bergman introduced asm-generic/unistd.h
> (into the linux kernel) to provide a generic interface to system
> calls. It does *not* define NR_ipc, and instead provides
> NR_msgsnd, msgrcv, msgget, msgctl etc. syscalls.
> 
> -- Current glibc (2.12.1, as well as the current eglibc) does
> not appear to use these new calls anywhere. Instead, glibc
> has generic (non-arch-specific) implementations of msgsnd
> etc.  that use the old NR_ipc interface (see, e.g.
> sysdeps/unix/sysv/linux/msgsnd.c, semget.c, shmdt.c, msgrcv.c,
> shmget.c, etc.)
> 
> Is someone working on patches to get glibc to use the new
> syscall interfaces (for IPC)?  Am I missing something? Seems like
> any arch wishing to use asm-generic/unistd.h and get glibc working
> gets to break new ground, here ... right?

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).

I expect that all of them will just use the same syscall ABI and glibc
port.

	Arnd

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

[Chris Metcalf]

 (Adding libc-ports to the cc list.)

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).
>
> I expect that all of them will just use the same syscall ABI and glibc
> port.

I'm happy to provide some previews of the work I'm doing to interested parties.

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.

In practice, of course, there's still lots of architecture-specific code
that is needed above and beyond the generic Linux subdirectory.  Our 32-bit
platform ("tile/tilepro") has an "Implies" file with
unix/sysv/linux/generic and unix/sysv/linux/generic/wordsize-32; our 64-bit
platform ("tile/tilegx") has an "Implies" file with unix/sysv/linux/generic
and unix/sysv/linux/wordsize-64.  Beyond that we have another 30-odd files
in sysdeps/unix/sysv/linux/tile to implement the non-NPTL part of our glibc
support, plus 50-odd files in sysdeps/tile.

I haven't provided an "nptl/sysdeps/unix/sysv/linux/generic/" directory
since there wasn't anything obviously generic about the "tile" support I
added for NPTL.

Another point where I'd appreciate guidance from libc-alpha is the sysctl()
and ustat() APIs.  The corresponding system calls are missing from
<asm-generic/unistd.h>, since they are deprecated and their functionality
is better provided by other means (/proc/sys, fstat).  So I've simply had
them return -1 with errno == ENOSYS.  Is there any reason to think they
merit more substantial work?  One could imagine baking in some horrible
mapping of "integer names" into path components for a sysctl()
implementation and reading /proc/sys to provide results, or walking all of
the mount points looking for a matching device number to pass a name to
fstat(), but I'm not sure it's worth the bloat to the library.

I have a few patches for the platform-independent glibc code, mostly for
things which are exposed in our platform but not in others.  E.g.
__readlink() in include/unistd.h returns the wrong type (int not ssize_t),
and some of the standard Linux implementations of things like fxstat64.c
need to be completely wrapped with "#ifndef XSTAT_IS_XSTAT64" so that
fxstat.c can provide the alias, since all the stat structures are the same
everywhere.  I will submit some separate patches to libc-alpha for this.

Thanks in advance for any feedback.  Please keep me cc'ed on any
discussions of the generic Linux syscall ABI.  Thanks!

sysdeps/unix/sysv/linux/generic/access.c
sysdeps/unix/sysv/linux/generic/bits/fcntl.h
sysdeps/unix/sysv/linux/generic/bits/sem.h
sysdeps/unix/sysv/linux/generic/bits/stat.h
sysdeps/unix/sysv/linux/generic/bits/typesizes.h
sysdeps/unix/sysv/linux/generic/chmod.c
sysdeps/unix/sysv/linux/generic/chown.c
sysdeps/unix/sysv/linux/generic/lxstat.c
sysdeps/unix/sysv/linux/generic/xstat.c
sysdeps/unix/sysv/linux/generic/Versions
sysdeps/unix/sysv/linux/generic/fxstatat.c
sysdeps/unix/sysv/linux/generic/lchown.c
sysdeps/unix/sysv/linux/generic/link.c
sysdeps/unix/sysv/linux/generic/readlink.c
sysdeps/unix/sysv/linux/generic/open.c
sysdeps/unix/sysv/linux/generic/open64.c
sysdeps/unix/sysv/linux/generic/pipe.c
sysdeps/unix/sysv/linux/generic/poll.c
sysdeps/unix/sysv/linux/generic/recv.c
sysdeps/unix/sysv/linux/generic/rmdir.c
sysdeps/unix/sysv/linux/generic/send.c
sysdeps/unix/sysv/linux/generic/symlink.c
sysdeps/unix/sysv/linux/generic/syscalls.list
sysdeps/unix/sysv/linux/generic/sysdep.h
sysdeps/unix/sysv/linux/generic/unlink.c
sysdeps/unix/sysv/linux/generic/xmknod.c
sysdeps/unix/sysv/linux/generic/sysctl.c
sysdeps/unix/sysv/linux/generic/readlink_chk.c
sysdeps/unix/sysv/linux/generic/ustat.c
sysdeps/unix/sysv/linux/generic/wordsize-32/fcntl.c
sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
sysdeps/unix/sysv/linux/generic/wordsize-32/ftruncate.c
sysdeps/unix/sysv/linux/generic/wordsize-32/fxstat.c
sysdeps/unix/sysv/linux/generic/wordsize-32/llseek.c
sysdeps/unix/sysv/linux/generic/wordsize-32/lseek.c
sysdeps/unix/sysv/linux/generic/wordsize-32/mmap.c
sysdeps/unix/sysv/linux/generic/wordsize-32/posix_fadvise.c
sysdeps/unix/sysv/linux/generic/wordsize-32/sendfile.c
sysdeps/unix/sysv/linux/generic/wordsize-32/statfs.c
sysdeps/unix/sysv/linux/generic/wordsize-32/truncate.c
sysdeps/unix/sysv/linux/generic/brk.c
sysdeps/unix/sysv/linux/generic/dl-origin.c
sysdeps/unix/sysv/linux/generic/umount.c
sysdeps/unix/sysv/linux/generic/creat.c
sysdeps/unix/sysv/linux/generic/pause.c
sysdeps/unix/sysv/linux/generic/Makefile
sysdeps/unix/sysv/linux/generic/select.c
sysdeps/unix/sysv/linux/generic/epoll_create.c
sysdeps/unix/sysv/linux/generic/epoll_wait.c
sysdeps/unix/sysv/linux/generic/inotify_init.c
sysdeps/unix/sysv/linux/generic/dup2.c
sysdeps/unix/sysv/linux/generic/mkdir.c
sysdeps/unix/sysv/linux/generic/rename.c
sysdeps/unix/sysv/linux/generic/utimes.c

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

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

[Joseph S. Myers]

On Tue, 28 Sep 2010, Chris Metcalf wrote:

>  (Adding libc-ports to the cc list.)
> 
> 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).

(Removing libc-alpha as my comments aren't relevant to that list.)

Two of the three seem rather surprising to me as regards glibc ports being 
ready to merge - maybe kernel ports are ready, however, it isn't clear to 
me what (kernel or glibc) the original comment was referring to.

C6X has no MMU so a glibc port isn't a possibility.  There are indeed 
uClibc and GCC ports we will be contributing in due course - but the 
linker support for shared objects is still in development (I contributed 
the static linking binutils support upstream earlier this year) and is 
required for building anything for uClinux userspace for this platform.

As for Nios II, we have a fully functional glibc port at CodeSourcery.  
It is I believe all our own work so there are no legal obstacles to our 
contributing it to the FSF - but upstream contribution would not really be 
useful without the GCC and binutils ports, and those ports (to which we 
added PIC and TLS support among other things) are based on code from 
Altera which is not covered by an FSF copyright assignment, so while the 
code is available we have no current plans for Nios II upstream 
contribution.

http://www.codesourcery.com/sgpp/portal/datasheet?target_arch=Nios+II&target_os=GNU%2FLinux

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Arnd Bergmann]

On Tuesday 28 September 2010, Joseph S. Myers wrote:
> (Removing libc-alpha as my comments aren't relevant to that list.)
> 
> Two of the three seem rather surprising to me as regards glibc ports being 
> ready to merge - maybe kernel ports are ready, however, it isn't clear to 
> me what (kernel or glibc) the original comment was referring to.

I was talking about kernel ports.
 
> C6X has no MMU so a glibc port isn't a possibility.  There are indeed 
> uClibc and GCC ports we will be contributing in due course - but the 
> linker support for shared objects is still in development (I contributed 
> the static linking binutils support upstream earlier this year) and is 
> required for building anything for uClinux userspace for this platform.

Right. Obviously the same question exists for uClibc though: The C6X syscall
ABI will need to be rewritten (as in deleted and replaced by generic
code) in the kernel in order to get merged, so the uClibc port will
have to gain the same kind of generic API that we need for glibc.

> As for Nios II, we have a fully functional glibc port at CodeSourcery.  
> It is I believe all our own work so there are no legal obstacles to our 
> contributing it to the FSF - but upstream contribution would not really be 
> useful without the GCC and binutils ports, and those ports (to which we 
> added PIC and TLS support among other things) are based on code from 
> Altera which is not covered by an FSF copyright assignment, so while the 
> code is available we have no current plans for Nios II upstream 
> contribution.
> 
> http://www.codesourcery.com/sgpp/portal/datasheet?target_arch=Nios+II&target_os=GNU%2FLinux

Same thing here. I wouldn't call the glibc port "fully functional" because
it does not cover a mainline Linux and getting the architecture tree
upstream means replacing the syscall ABI with a proper one.

Once the kernel parts are upstream and use the generic syscall ABI, only
rudimentary architecture support in glibc would be needed.

	Arnd

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

[Joseph S. Myers]

On Tue, 28 Sep 2010, Arnd Bergmann wrote:

> Once the kernel parts are upstream and use the generic syscall ABI, only
> rudimentary architecture support in glibc would be needed.

In my experience very little of a glibc port relates to the particular set 
of syscalls present on a particular architecture (and what does often 
consists of one-line files that #include the file for i386 or some other 
convenient architecture); changing a port from an old syscall ABI to the 
generic one would mean making it use the new set of generic files in 
preference to some existing sysdeps/unix/sysv/linux files, and maybe 
having fewer bits/ headers if some of the architecture differences there 
are avoided, but no real differences to any of the bits that aren't purely 
mechanical such as the implementation of each architecture's TLS ABI, 
other pieces of the ELF ABI, the set of atomic operations available, 
startup code, longjmp, profiling, clone, the interface used to call an 
individual syscall, etc. - remember that you can't build any vaguely 
recent glibc without full shared library and NPTL support.

A lot of the *changes made to maintain an existing port* relate to 
constants in the duplicated bits/* headers which it might be good to 
duplicate less if future architectures share values for all the constants, 
but that's not where most of the complexity in the port lies.  MIPS is 
probably the worst case for code dealing with syscall ABI peculiarities 
(given the three different ABIs, and n64 having different userspace stat 
and stat64 structures), but even there they aren't much of a source of 
complexity (MIPS ELF peculiarities are much more an issue).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1773 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1090 bytes --]

On Tuesday, September 28, 2010 12:13:56 Arnd Bergmann wrote:
> On Tuesday 28 September 2010, Joseph S. Myers wrote:
> > C6X has no MMU so a glibc port isn't a possibility.  There are indeed
> > uClibc and GCC ports we will be contributing in due course - but the
> > linker support for shared objects is still in development (I contributed
> > the static linking binutils support upstream earlier this year) and is
> > required for building anything for uClinux userspace for this platform.
> 
> Right. Obviously the same question exists for uClibc though: The C6X
> syscall ABI will need to be rewritten (as in deleted and replaced by
> generic code) in the kernel in order to get merged, so the uClibc port
> will have to gain the same kind of generic API that we need for glibc.

i dont think uClibc needs nearly as much work as glibc.  it already goes out 
of its way to avoid code duplication whenever possible (and then some).  the 
position glibc takes wrt copy & paste at the file level makes me ill and so i 
tend to double down in my uClibc efforts there.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Joseph S. Myers]

On Tue, 28 Sep 2010, Mike Frysinger wrote:

> 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.

A generic port would be useful for new architectures with MMU - but the 
notion that "only rudimentary architecture support in glibc would be 
needed" is mistaken.  Note Chris's figures "another 30-odd files in 
sysdeps/unix/sysv/linux/tile to implement the non-NPTL part of our glibc 
support, plus 50-odd files in sysdeps/tile" - hardly rudimentary.  Those 
seem the right order of magnitude, if larger than the minimum; the Nios II 
port currently has 59 new files in sysdeps directories, most of which I 
expect would still be needed with the generic syscall ABI.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Linas Vepstas]

Hi Chris,

On 28 September 2010 08:05, Chris Metcalf <cmetcalf@tilera.com> wrote:
>  (Adding libc-ports to the cc list.)
>
> 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).
>>
>> I expect that all of them will just use the same syscall ABI and glibc
>> port.
>
> I'm happy to provide some previews of the work I'm doing to interested parties.

Yes, this is exactly what I'm looking for!  I'd love to "preview" the
code; it'll take a good long while to get everything built and tested,
so feeback might take a while ...

Any chance that these could be split out as a distinct set of patches,
taken apart from the tilera arch port, and submitted upstream
independently (to glibc and/or ports collection)?  I'll help w/ patch
preparation...

> I have a few patches for the platform-independent glibc code, mostly for
> things which are exposed in our platform but not in others.  E.g.
> __readlink() in include/unistd.h returns the wrong type (int not ssize_t),
> and some of the standard Linux implementations of things like fxstat64.c
> need to be completely wrapped with "#ifndef XSTAT_IS_XSTAT64" so that
> fxstat.c can provide the alias, since all the stat structures are the same
> everywhere.  I will submit some separate patches to libc-alpha for this.

Yes, I presume that arch-indep fixes can/should be submitted even
before a port is ready.  I do notice that the glibc maintainers can be
somewhat reticent of accepting these, for fear of accidentally breaking
working code.

-- Linas

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

[Arnd Bergmann]

On Tuesday 28 September 2010 18:41:41 Joseph S. Myers wrote:
> In my experience very little of a glibc port relates to the particular set 
> of syscalls present on a particular architecture (and what does often 
> consists of one-line files that #include the file for i386 or some other 
> convenient architecture); changing a port from an old syscall ABI to the 
> generic one would mean making it use the new set of generic files in 
> preference to some existing sysdeps/unix/sysv/linux files, and maybe 
> having fewer bits/ headers if some of the architecture differences there 
> are avoided, but no real differences to any of the bits that aren't purely 
> mechanical such as the implementation of each architecture's TLS ABI, 
> other pieces of the ELF ABI, the set of atomic operations available, 
> startup code, longjmp, profiling, clone, the interface used to call an 
> individual syscall, etc. - remember that you can't build any vaguely 
> recent glibc without full shared library and NPTL support.
> 
> A lot of the changes made to maintain an existing port relate to 
> constants in the duplicated bits/* headers which it might be good to 
> duplicate less if future architectures share values for all the constants, 
> but that's not where most of the complexity in the port lies.  MIPS is 
> probably the worst case for code dealing with syscall ABI peculiarities 
> (given the three different ABIs, and n64 having different userspace stat 
> and stat64 structures), but even there they aren't much of a source of 
> complexity (MIPS ELF peculiarities are much more an issue).

Good point. As a kernel developer I tend to see glibc too much as
just a front-end for the system calls, but of course you are right
that it is much more that requires a lot of hard work for an architecture
port.
I did not mean to discredit the good work that has gone into the nios2
port or any part of upstream glibc.

The question that Linas was asking is specifically about the syscall
ABI and this is what I'm mostly interested in as well. A significant
part of the maintainance work in the kernel is just keeping up with
syscall ABI changes, which now gets minimized for new architectures.

	Arnd

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

[Christoph Hellwig]

On Tue, Sep 28, 2010 at 09:05:13AM -0400, Chris Metcalf wrote:
> Another point where I'd appreciate guidance from libc-alpha is the sysctl()
> and ustat() APIs.  The corresponding system calls are missing from
> <asm-generic/unistd.h>, since they are deprecated and their functionality
> is better provided by other means (/proc/sys, fstat).  So I've simply had
> them return -1 with errno == ENOSYS.  Is there any reason to think they
> merit more substantial work?  One could imagine baking in some horrible
> mapping of "integer names" into path components for a sysctl()
> implementation and reading /proc/sys to provide results, or walking all of
> the mount points looking for a matching device number to pass a name to
> fstat(), but I'm not sure it's worth the bloat to the library.

fstat does not replace ustat.  ustat is a statf-subsystem by dev_t and
is not replaced by anything.  xfsprogs for example uses it to check if
a given dev_t is currently mounted.  Please add it to the generic code.

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

[Arnd Bergmann]

On Wednesday 29 September 2010, Christoph Hellwig wrote:
> On Tue, Sep 28, 2010 at 09:05:13AM -0400, Chris Metcalf wrote:
> > Another point where I'd appreciate guidance from libc-alpha is the sysctl()
> > and ustat() APIs.  The corresponding system calls are missing from
> > <asm-generic/unistd.h>, since they are deprecated and their functionality
> > is better provided by other means (/proc/sys, fstat).  So I've simply had
> > them return -1 with errno == ENOSYS.  Is there any reason to think they
> > merit more substantial work?  One could imagine baking in some horrible
> > mapping of "integer names" into path components for a sysctl()
> > implementation and reading /proc/sys to provide results, or walking all of
> > the mount points looking for a matching device number to pass a name to
> > fstat(), but I'm not sure it's worth the bloat to the library.
> 
> fstat does not replace ustat.  ustat is a statf-subsystem by dev_t and
> is not replaced by anything.  xfsprogs for example uses it to check if
> a given dev_t is currently mounted.  Please add it to the generic code.
> 

I didn't put it into the generic list because the man page claims

 "ustat() is deprecated and has only been provided for compatibility.
  All new programs should use statfs(2) instead."

I suppose that means we should change the man page as well, right?

	Arnd

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

[Chris Metcalf]

 On 9/28/2010 1:36 PM, Linas Vepstas wrote:
> On 28 September 2010 08:05, Chris Metcalf <cmetcalf@tilera.com> 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).
>>>
>> I'm happy to provide some previews of the work I'm doing to interested parties.
> Yes, this is exactly what I'm looking for!  I'd love to "preview" the
> code; it'll take a good long while to get everything built and tested,
> so feeback might take a while ...
>
> Any chance that these could be split out as a distinct set of patches,
> taken apart from the tilera arch port, and submitted upstream
> independently (to glibc and/or ports collection)?  I'll help w/ patch
> preparation...

At this point I'm probably a week away from having something with the
obvious bugs all fixed, at which point I can start submitting it back
upstream.  The few patches I have to common infrastructure I'll just submit
to libc-alpha as git patches, then I'll probably just send a two-part patch
set to libc-ports, one with the linux/generic stuff, and one with the
tile-specific stuff.  (It looks like changes are never made as "git pull"
requests on the glibc lists, just as emailed unidiffs -- someone correct me
if I'm wrong.)

Linas, if you can wait a week I'd rather have you see the stuff I believe
to be working 100% to get maximum use out of you as a reviewer :-)  If you
need it sooner, of course, I'm happy to let you have something now.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

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

[Linas Vepstas]

Hi Chris,

A question, and a patch follow:

On 28 September 2010 08:05, Chris Metcalf <cmetcalf@tilera.com> wrote:
>  (Adding libc-ports to the cc list.)
>
> 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).
>>
>> I expect that all of them will just use the same syscall ABI and glibc
>> port.
>
> I'm happy to provide some previews of the work I'm doing to interested parties.
[...]

> sysdeps/unix/sysv/linux/generic/access.c
> sysdeps/unix/sysv/linux/generic/bits/fcntl.h
> sysdeps/unix/sysv/linux/generic/bits/sem.h
> sysdeps/unix/sysv/linux/generic/bits/stat.h
> sysdeps/unix/sysv/linux/generic/bits/typesizes.h
> sysdeps/unix/sysv/linux/generic/chmod.c
> sysdeps/unix/sysv/linux/generic/chown.c
> sysdeps/unix/sysv/linux/generic/lxstat.c
> sysdeps/unix/sysv/linux/generic/xstat.c
> sysdeps/unix/sysv/linux/generic/Versions
> sysdeps/unix/sysv/linux/generic/fxstatat.c
> sysdeps/unix/sysv/linux/generic/lchown.c
> sysdeps/unix/sysv/linux/generic/link.c
> sysdeps/unix/sysv/linux/generic/readlink.c
> sysdeps/unix/sysv/linux/generic/open.c
> sysdeps/unix/sysv/linux/generic/open64.c
> sysdeps/unix/sysv/linux/generic/pipe.c
> sysdeps/unix/sysv/linux/generic/poll.c
> sysdeps/unix/sysv/linux/generic/recv.c
> sysdeps/unix/sysv/linux/generic/rmdir.c
> sysdeps/unix/sysv/linux/generic/send.c
> sysdeps/unix/sysv/linux/generic/symlink.c
> sysdeps/unix/sysv/linux/generic/syscalls.list
> sysdeps/unix/sysv/linux/generic/sysdep.h
> sysdeps/unix/sysv/linux/generic/unlink.c
> sysdeps/unix/sysv/linux/generic/xmknod.c
> sysdeps/unix/sysv/linux/generic/sysctl.c
> sysdeps/unix/sysv/linux/generic/readlink_chk.c
> sysdeps/unix/sysv/linux/generic/ustat.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/fcntl.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/ftruncate.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/fxstat.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/llseek.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/lseek.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/mmap.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/posix_fadvise.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/sendfile.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/statfs.c
> sysdeps/unix/sysv/linux/generic/wordsize-32/truncate.c
> sysdeps/unix/sysv/linux/generic/brk.c
> sysdeps/unix/sysv/linux/generic/dl-origin.c
> sysdeps/unix/sysv/linux/generic/umount.c
> sysdeps/unix/sysv/linux/generic/creat.c
> sysdeps/unix/sysv/linux/generic/pause.c
> sysdeps/unix/sysv/linux/generic/Makefile
> sysdeps/unix/sysv/linux/generic/select.c
> sysdeps/unix/sysv/linux/generic/epoll_create.c
> sysdeps/unix/sysv/linux/generic/epoll_wait.c
> sysdeps/unix/sysv/linux/generic/inotify_init.c
> sysdeps/unix/sysv/linux/generic/dup2.c
> sysdeps/unix/sysv/linux/generic/mkdir.c
> sysdeps/unix/sysv/linux/generic/rename.c
> sysdeps/unix/sysv/linux/generic/utimes.c

I note that this hasn't been merged into glibc-2.13, any particular
explaintation
for that?

Anyway, it seems that pthread cancellation pints are missing
from a couple of the functions.  e.g. for send, recv, one needs
the following:

Index: glibc-2.13/sysdeps/unix/sysv/linux/generic/send.c
===================================================================
--- glibc-2.13.orig/sysdeps/unix/sysv/linux/generic/send.c	2011-03-10
10:26:48.000000000 -0600
+++ glibc-2.13/sysdeps/unix/sysv/linux/generic/send.c	2011-03-10
10:26:55.000000000 -0600
@@ -18,12 +18,25 @@

 #include <stdlib.h>
 #include <sys/types.h>
-#include <sysdep.h>
+#include <sysdep-cancel.h>
 #include <libc-symbols.h>

 ssize_t __libc_send(int sockfd, const void *buffer, size_t len, int flags)
 {
-  return INLINE_SYSCALL (sendto, 6, sockfd, buffer, len, flags, NULL, 0);
+  ssize_t result;
+
+  if (SINGLE_THREAD_P)
+    result = INLINE_SYSCALL (sendto, 6, sockfd, buffer, len, flags, NULL, 0);
+  else
+    {
+      int oldtype = LIBC_CANCEL_ASYNC ();
+
+      result = INLINE_SYSCALL (sendto, 6, sockfd, buffer, len, flags, NULL, 0);
+
+      LIBC_CANCEL_RESET (oldtype);
+    }
+
+  return result;
 }

 strong_alias (__libc_send, __send)

and likewise for recv ...

--linas

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

[Chris Metcalf]

On 3/10/2011 11:46 AM, Linas Vepstas wrote:
> Hi Chris,
>
> A question, and a patch follow:
>
> On 28 September 2010 08:05, Chris Metcalf <cmetcalf@tilera.com> wrote:
>>  (Adding libc-ports to the cc list.)
>>
>> 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).
>>>
>>> I expect that all of them will just use the same syscall ABI and glibc
>>> port.
>> [...]
> I note that this hasn't been merged into glibc-2.13, any particular
> explaintation for that?

Just that I haven't had the time -- I've been more focused on the kernel
community rather than glibc.  I'm still planning to do it when I have some
time!

> Anyway, it seems that pthread cancellation pints are missing
> from a couple of the functions.  e.g. for send, recv, one needs
> the following:

Thanks, that seems very plausible.  I'll update my copy of those sources so
it will be in the eventual submission to libc-ports.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com