* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 13:05 ` Chris Metcalf
@ 2010-09-28 15:52 ` Joseph S. Myers
2010-09-28 16:13 ` Arnd Bergmann
2010-09-28 16:42 ` Mike Frysinger
` (3 subsequent siblings)
4 siblings, 1 reply; 17+ messages in thread
From: Joseph S. Myers @ 2010-09-28 15:52 UTC (permalink / raw)
To: Chris Metcalf
Cc: Arnd Bergmann, linasvepstas, linux-kernel, libc-ports, andrew
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 15:52 ` Joseph S. Myers
@ 2010-09-28 16:13 ` Arnd Bergmann
2010-09-28 16:41 ` Joseph S. Myers
2010-09-28 16:50 ` Mike Frysinger
0 siblings, 2 replies; 17+ messages in thread
From: Arnd Bergmann @ 2010-09-28 16:13 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Chris Metcalf, linasvepstas, linux-kernel, libc-ports, andrew
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 16:13 ` Arnd Bergmann
@ 2010-09-28 16:41 ` Joseph S. Myers
2010-09-28 20:08 ` Arnd Bergmann
2010-09-28 16:50 ` Mike Frysinger
1 sibling, 1 reply; 17+ messages in thread
From: Joseph S. Myers @ 2010-09-28 16:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Chris Metcalf, linasvepstas, linux-kernel, libc-ports, andrew
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 16:41 ` Joseph S. Myers
@ 2010-09-28 20:08 ` Arnd Bergmann
0 siblings, 0 replies; 17+ messages in thread
From: Arnd Bergmann @ 2010-09-28 20:08 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Chris Metcalf, linasvepstas, linux-kernel, libc-ports, andrew
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 16:13 ` Arnd Bergmann
2010-09-28 16:41 ` Joseph S. Myers
@ 2010-09-28 16:50 ` Mike Frysinger
1 sibling, 0 replies; 17+ messages in thread
From: Mike Frysinger @ 2010-09-28 16:50 UTC (permalink / raw)
To: libc-ports
Cc: Arnd Bergmann, Joseph S. Myers, Chris Metcalf, linasvepstas,
linux-kernel, andrew
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 13:05 ` Chris Metcalf
2010-09-28 15:52 ` Joseph S. Myers
@ 2010-09-28 16:42 ` Mike Frysinger
2010-09-28 16:52 ` Joseph S. Myers
2010-09-28 17:36 ` Linas Vepstas
` (2 subsequent siblings)
4 siblings, 1 reply; 17+ messages in thread
From: Mike Frysinger @ 2010-09-28 16:42 UTC (permalink / raw)
To: libc-ports
Cc: Chris Metcalf, Arnd Bergmann, linasvepstas, GLIBC Devel,
linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 16:42 ` Mike Frysinger
@ 2010-09-28 16:52 ` Joseph S. Myers
0 siblings, 0 replies; 17+ messages in thread
From: Joseph S. Myers @ 2010-09-28 16:52 UTC (permalink / raw)
To: Mike Frysinger
Cc: libc-ports, Chris Metcalf, Arnd Bergmann, linasvepstas,
GLIBC Devel, linux-kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 13:05 ` Chris Metcalf
2010-09-28 15:52 ` Joseph S. Myers
2010-09-28 16:42 ` Mike Frysinger
@ 2010-09-28 17:36 ` Linas Vepstas
2010-09-30 13:23 ` Chris Metcalf
2010-09-29 5:16 ` Christoph Hellwig
2011-03-10 16:46 ` Linas Vepstas
4 siblings, 1 reply; 17+ messages in thread
From: Linas Vepstas @ 2010-09-28 17:36 UTC (permalink / raw)
To: Chris Metcalf; +Cc: Arnd Bergmann, GLIBC Devel, linux-kernel, libc-ports
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 17:36 ` Linas Vepstas
@ 2010-09-30 13:23 ` Chris Metcalf
0 siblings, 0 replies; 17+ messages in thread
From: Chris Metcalf @ 2010-09-30 13:23 UTC (permalink / raw)
To: linasvepstas; +Cc: Arnd Bergmann, GLIBC Devel, linux-kernel, libc-ports
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 13:05 ` Chris Metcalf
` (2 preceding siblings ...)
2010-09-28 17:36 ` Linas Vepstas
@ 2010-09-29 5:16 ` Christoph Hellwig
2010-09-29 11:55 ` Arnd Bergmann
2011-03-10 16:46 ` Linas Vepstas
4 siblings, 1 reply; 17+ messages in thread
From: Christoph Hellwig @ 2010-09-29 5:16 UTC (permalink / raw)
To: Chris Metcalf
Cc: Arnd Bergmann, linasvepstas, GLIBC Devel, linux-kernel,
libc-ports
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-29 5:16 ` Christoph Hellwig
@ 2010-09-29 11:55 ` Arnd Bergmann
0 siblings, 0 replies; 17+ messages in thread
From: Arnd Bergmann @ 2010-09-29 11:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Chris Metcalf, linasvepstas, GLIBC Devel, linux-kernel,
libc-ports
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: asm-generic/unistd.h and glibc use of NR_ipc
2010-09-28 13:05 ` Chris Metcalf
` (3 preceding siblings ...)
2010-09-29 5:16 ` Christoph Hellwig
@ 2011-03-10 16:46 ` Linas Vepstas
2011-03-10 17:07 ` Chris Metcalf
4 siblings, 1 reply; 17+ messages in thread
From: Linas Vepstas @ 2011-03-10 16:46 UTC (permalink / raw)
To: Chris Metcalf; +Cc: Arnd Bergmann, GLIBC Devel, linux-kernel, libc-ports
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: asm-generic/unistd.h and glibc use of NR_ipc
2011-03-10 16:46 ` Linas Vepstas
@ 2011-03-10 17:07 ` Chris Metcalf
0 siblings, 0 replies; 17+ messages in thread
From: Chris Metcalf @ 2011-03-10 17:07 UTC (permalink / raw)
To: linasvepstas; +Cc: Arnd Bergmann, GLIBC Devel, linux-kernel, libc-ports
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
^ permalink raw reply [flat|nested] 17+ messages in thread