recent (12-18 or so) 2.1 changes to use __libc_*

recent (12-18 or so) 2.1 changes to use __libc_*

[Roland McGrath]

What is the story on the following changes?
That is, three questions: What is the general story on __libc_foo vs __foo
vs foo this week?  What was the specific reason for this set of changes to
use more __libc_foo instead of __foo or foo?  And why was such a change
worthy of going into 2.1?

It turns out this is what broke the hurd (I left town just before this
change and am still out on vacation and not able to hack very conveniently;
last night was the first time I rebuilt libc since).  It just happened to
alert me to the situation with posix/pread.c et al (on which my opinions
have not changed).  


  1999-12-18  Ulrich Drepper  <drepper@cygnus.com>

	  * include/unistd.h: Declare __libc_open64, __libc_lseek64,
	  __libc_pread, __libc_pread64, __libc_pwrite, and __libc_pwrite64.
	  * io/Versions: Export __libc_open64 and __libc_lseek64.
	  * posix/Versions: Export __libc_pread, __libc_pread64, __libc_pwrite,
	  and __libc_pwrite64.
	  * sysdeps/generic/open64.c: Define __libc_* variant for cancelation
	  wrapper.
	  * sysdeps/generic/pread.c: Likewise.
	  * sysdeps/generic/pread64.c: Likewise.
	  * sysdeps/generic/pwrite.c: Likewise.
	  * sysdeps/generic/pwrite64.c: Likewise.
	  * sysdeps/posix/open64.c: Likewise.
	  * sysdeps/posix/pread.c: Likewise.
	  * sysdeps/posix/pread64.c: Likewise.
	  * sysdeps/posix/pwrite.c: Likewise.
	  * sysdeps/posix/pwrite64.c: Likewise.
	  * sysdeps/unix/sysv/linux/llseek.c: Likewise.
	  * sysdeps/unix/sysv/linux/pread.c: Likewise.
	  * sysdeps/unix/sysv/linux/pread64.c: Likewise.
	  * sysdeps/unix/sysv/linux/pwrite.c: Likewise.
	  * sysdeps/unix/sysv/linux/pwrite64.c: Likewise.
	  * sysdeps/unix/sysv/linux/i386/pread.c: Likewise.
	  * sysdeps/unix/sysv/linux/i386/pread64.c: Likewise.
	  * sysdeps/unix/sysv/linux/i386/pwrite.c: Likewise.
	  * sysdeps/unix/sysv/linux/i386/pwrite64.c: Likewise.

	  * sysdeps/posix/open64.c: Help gcc generating better code.

	  * sysdeps/generic/libc-start.c (check_one_fd): Use __libc_open
	  instead of __open.

  1999-12-11  H.J. Lu  <hjl@gnu.org>

	  * sysdeps/generic/libc-start.c (check_one_fd): Use __libc_fcntl
	  instead of __fcntl.

Re: recent (12-18 or so) 2.1 changes to use __libc_*

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> And why was such a change worthy of going into 2.1?

The problem was that these functions were no cancellation points which
made the behaviour of some programs differently on how they were
configured (using write vs pwrite etc).

There should be absolutely no change in the program behaviour for
non-thread programs and threaded programs (using LinuxThreads) now see
this functions as cancellation points.


The __libc_fcntl change in the startup code was necessary so that we
are not calling the wrapper functions at a point of time when the
thread library was not yet initialized.

> It turns out this is what broke the hurd

I would like to see how this can be the case.  All I can imagine is
that a program is fiddling with the symbols and tries to overload
them.  If you mean it does not compile, yes, the new names must be
available.  But this change was made a long time ago and since then
somebody really should have tried compiling.  If you'd tell me nobody
has the time to do this I would try to change the Hurd-specific files
myself.  So far it was not necesary and since I wouldn't be able to
verify the result it's also more dangerous.

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

Re: recent (12-18 or so) 2.1 changes to use __libc_*

[Roland McGrath]

> If you mean it does not compile, yes, the new names must be
> available.  But this change was made a long time ago and since then
> somebody really should have tried compiling.

That is exactly what I mean.  Please remember that the Hurd project is
truly all-volunteer, with noone being paid by anyone to do any part of it,
and really only Mark Kettenis and I are likely to track down libc things.
It is not an unreasonable expectation for the "stable releae branch" that
things not get broken while we're busy having lives.  And on January 5th to
say "a long time ago" about something done the weekend before Christmas, is
really just plain ludicrous.  Even if it were more than volunteering spare
time, I am still on bloody vacation 3000 miles from my computer and have
not been in a position to do real development since days before you made
these changes.  If I hadn't just gotten bored last night, I might not have
noticed it for another two weeks.  (So this is the first xmas season in
recent memory that I haven't been huddled over my machine hacking GNU
crapola the whole time anyway, but at least give me the benefit of the
doubt for maybe having a social life once in a while.)

> If you'd tell me nobody has the time to do this I would try to change the
> Hurd-specific files myself.  So far it was not necesary and since I
> wouldn't be able to verify the result it's also more dangerous.

Multiple answers.  It doesn't hurt for you to make this kind of change
yourself, since we will notice it and make sure it's kosher eventually.  In
fact, had you made the change and got it all wrong, we would have probably
noticed that sooner.  But you don't need to.  In general, there is time to
do reasonable maintenance, but since 2.1 has been stable we are not on top
of it every day; when you said "2.1.3 soon", I went to make sure things
looked ok for the hurd, and then I noticed it.  I don't know what else you
expect.  I haven't heard from Mark in a while, perhaps he's off having a
life.  And debugging libc over 56k from my mother's Macintosh was not my
first choice of fun vacation activity either.


Roland

Re: recent (12-18 or so) 2.1 changes to use __libc_*

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> That is exactly what I mean.  Please remember that the Hurd project is
> truly all-volunteer, with noone being paid by anyone to do any part of it,
> and really only Mark Kettenis and I are likely to track down libc things.

I don't know about the SuSE guys, but I am also not paid to do Linux
glibc work.

> And on January 5th to say "a long time ago" about something done the
> weekend before Christmas, is really just plain ludicrous.

Sorry, this wasn't always the case and I don't know when it changed
for you.  If there are problems with maintaining the speed of the
development I would have expected that somebody told me.  For the
changes in question it would have been possible to do the work even
without Hurd compilation possibilities.

> (So this is the first xmas season in recent memory that I haven't
> been huddled over my machine hacking GNU crapola the whole time
> anyway, but at least give me the benefit of the doubt for maybe
> having a social life once in a while.)

I don't know why you feel attaked personally.  Nobody demands that you
do the work all by yourself.  But I will also not allow that the slow
Hurd development is slowing down the development on Linux as well.  It
is no problem to be behind, just let your users know about this.  When
I make a release I can easily say that this is not for Hurd.  Maybe
this would even lead to people offering to help.

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