In article <20061122132135.GA4136@NetBSD.org>,
Pavel Cahyna  <pavel@NetBSD.org> wrote:
>On Tue, Nov 21, 2006 at 08:18:35PM -0500, Thor Lancelot Simon wrote:
>> On Tue, Nov 21, 2006 at 11:16:24PM +0100, Pavel Cahyna wrote:
>> > On Tue, Nov 21, 2006 at 06:15:37PM +0000, Christos Zoulas wrote:
>> > 
>> > > 3. In 3.2.6, mention that we usually implement the older version of the
>> > >    syscall in libc so that we can provide binary compatibility for
>> > >    dynamically linked libraries without needing the kernel support.
>> > 
>> > This was already there.
>> 
>> I think this is a highly misleading explanation anyway.  We implement
>> the older version of the syscall in libc because we are afraid to bump
>> the libc major number, and thus we *must* provide every function that
>> was ever present there.
>
>I think this is not true. You explain why do we have to provide the
>function in libc, but not why is it implemented using the new syscall.
>It could be also done as a wrapper around the compat syscall.

Statically linked code will use the kernel compat code. Dynamically linked
code will use the libc wrapper. Without the libc wrapper, dynamically
linked programs don't work.

christos