policy on __libc_*

policy on __libc_*

[Roland McGrath]

Regardless of the other bickering, I don't think I got a clear answer on
the question of what the general policy is about __libc_foo names.  I've
just __libc_ified lseek, open, and fcntl for the hurd since other things
have come to use those.  This is a non-issue for the hurd, since
cancellation is handled entirely differently (the __libc_foo, __foo, and
foo names are all aliases for the same thing regardless), but it would be
nice to know what to expect from the os-independent parts of libc.

Re: policy on __libc_*

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> but it would be nice to know what to expect from the os-independent
> parts of libc.

You are right, that would be nice.  But I really have no time to write
this all down in detail.  I think I've explained on the list a few
times already that the __libc_* names are introduced for cancelation
points since the functions must be intercepted even when called from
inside the libc.  I.e., the __* functions also have to be exported.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: policy on __libc_*

[Roland McGrath]

> You are right, that would be nice.  But I really have no time to write
> this all down in detail.  I think I've explained on the list a few
> times already that the __libc_* names are introduced for cancelation
> points since the functions must be intercepted even when called from
> inside the libc.  I.e., the __* functions also have to be exported.

I did not ask why they exist, I do already know that.  I asked which
functions need them.  All libc functions that are POSIX.1 cancellation
points?  Only some of them?  Is there a rule, or are we doing it as needed?

Re: policy on __libc_*

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> I did not ask why they exist, I do already know that.  I asked which
> functions need them.  All libc functions that are POSIX.1 cancellation
> points?  Only some of them?

Some of the,

> Is there a rule, or are we doing it as needed?

The list of functions can be seen easily from the wrapsyscall.c file
on the linuxthreads add-on:

close
fcntl
fsync
lseek
lseek64
msync
nanosleep
open
open64
pause
pread
pread64
pwrite
pwrite64
read
system
tcdrain
wait
waitpid
write
accept
connect
recv
recvfrom
recvmsg
send
sendmsg
sento

They are also described in POSIX (except that POSIX is not mentioning
the 64bit variants yet).

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: policy on __libc_*

[Roland McGrath]

> Roland McGrath <roland@frob.com> writes:
> 
> > I did not ask why they exist, I do already know that.  I asked which
> > functions need them.  All libc functions that are POSIX.1 cancellation
> > points?  Only some of them?
> 
> Some of the,

Huh?

> > Is there a rule, or are we doing it as needed?
> 
> The list of functions can be seen easily from the wrapsyscall.c file
> on the linuxthreads add-on:

Ok.  I also have 1003.1-1996 at home to consult, so the complete list is
available to me.  But I remain unclear on the answer to my question,
perhaps the missing first paragraph of your message contains it.

Re: policy on __libc_*

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> Ok.  I also have 1003.1-1996 at home to consult, so the complete list is
> available to me.  But I remain unclear on the answer to my question,
> perhaps the missing first paragraph of your message contains it.

This was menat to be a full stop, no further explanation planned.  But
I can give you one.  Only those POSIX functions which can block are
cancelation points.  These are almost all functions handling
file/terminal I/O but not something like tcgetattr.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: policy on __libc_*

[Roland McGrath]

> This was menat to be a full stop, no further explanation planned.  But
> I can give you one.

Yet you have not.  You continue to talk about which functions are
cancellation points, when I know about all of those.  You have not said
whether all those functions are to be renamed __libc_foo or only some and
if only some then how those are selected.

Re: policy on __libc_*

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> Yet you have not.  You continue to talk about which functions are
> cancellation points, when I know about all of those.  You have not said
> whether all those functions are to be renamed __libc_foo or only some and
> if only some then how those are selected.

All of the cancelation points have the official name __libc_*.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: policy on __libc_*

[Roland McGrath]

> All of the cancelation points have the official name __libc_*.

Thank you!  Finally!  How I was supposed to glean this from "Some the,"
I will never comprehend, but that we can let pass.