--B4IIlcmfBL/1gGOG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 11, 2007 at 08:52:50PM +0100, David Laight wrote:
> On Thu, Oct 11, 2007 at 09:30:31PM +0300, Aleksey Cheusov wrote:
> >=20
> > BTW. Can anybody explain what does "function renaming" mean
>=20
> It makes a function (eg):
>=20
> extern void foo(void);
>=20
> generate a reference to a symbol other than 'foo'.
>=20
> > any why it is used in NetBSD?
>=20
> For backwards compatibility.
> Typically if the prototype of a library function has to be changed (or
> if the layout of a structure if refers to changes), then the new function
> in the new library is renamed so that a 'compat' function can be defined
> in order to support old binaries (or not defined so that they don't load).
> This is all rather better than having old programs silently supply the
> wrong arguments.

David's 100% correct, but I wanted to try explaining this a different way=
=20
to help folks come up to speed on what's happening. Here's the historical=
=20
explanation. It's long-winded, but I hope it explains everything. :-)

NetBSD started with a stat() system call. This call causes information on=
=20
a file to be written into a structure the caller provides.

Being a system call, this maps to a function call stub in libc that
actually triggers the system call.  Staticly-linked programs have this
stub code embedded in them. Dynamicly-linked programs called this stub in
libc.

The original stat call used 16-bit quantities for a number of things, like
uids and gids, that we want to be 32-bit now. So how do we do that?

First, we come up with a new stat structure and make kernel code that=20
supports it. Easy.

The big question though is how we change stat() w/o breaking old programs.
There really are two parts of it, and we were lazy with one of them.

To keep staticly-linked programs working, we have to have a system call=20
that takes the old args. We do, and it's enabled with the right COMPAT=20
option. So we have two "stat" routines, with different system call=20
numbers, that handle the old and new formats. Not too hard.

To keep dynamically-linked programs working, we had two options. We could=
=20
write a stub routine in libc that did the right translation from what the=
=20
new call returns to what the old one expected. Or we could just leave the=
=20
stub pointing to the old system call. We chose the latter, since it means=
=20
we have only one copy of the translation code.

Ok, so we have old programs still working. But I still haven't talked=20
about renaming yet.

We use renaming to help us have new programs actually use the new struct=20
stat. It's easy to just change "struct stat" in the right header. The=20
thing though is that we want new programs to call a routine (either libc=20
or system call) that expects this new struct stat. According to standards=
=20
and how folks write programs, you call "stat()" and pass in the pointer to=
=20
a struct stat. struct stat in the headers now is our new structure, but by=
=20
the above discussion, "stat()" in libc is the routine that expects the old=
=20
structure.

Renaming lets us patch the two things together. With it, your C code that=
=20
is written to call "stat()" really calls "__stat30()" which is the routine=
=20
(stub in libc for the syscall) that expects the new stat structure.

So that's how we use renaming. We actually like it a lot. :-) We've done=20
it a number of times for struct stat...

Take care,

Bill

--B4IIlcmfBL/1gGOG
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFHDp/6Wz+3JHUci9cRAhhWAJ48y/iGnzyXJEUgXDZp8QBvvDc03ACbBo3V
g4S+TgOuiY6YZEjsar9TYlQ=
=xHM3
-----END PGP SIGNATURE-----

--B4IIlcmfBL/1gGOG--