Re: klibc development release

[Matti Aarnio]

On Fri, Aug 09, 2002 at 12:14:00PM -0700, H. Peter Anvin wrote:
> David Mosberger wrote:
...
> >Alpha calls umount2() "oldumount"; ia64 never had a one-argument
> >version of umount(), so there is no point creating legacy (and the
> >naming is inconsistent anyhow...).
> 
> The gratuitous inconsistencies between platforms is something that is 
> currently driving me up the wall.  I'm starting to think the NetBSD 
> people have the right idea: when you add a system call on NetBSD, you 
> only have to add it in one place and it becomes available on all the 
> platforms they support.

  History...   Initially I thought you are describing something
  different from Linux model (after all, different platforms have
  different ABIs for syscalls, leading to different call-vector
  tables, etc.)  but no, I see no difference from this description.

  How NetBSD handles the issue, I don't know.   One interpretation
  of what you say is that when a new architecture is added to NetBSD,
  it will instantly inherit the entire historical set of syscalls,
  including the obsolete ones.

  As long as old calls are supported, the kernel needs to know
  how to handle a call serving some thing 10 years ago.. ( e.g.
  "oldumount").  Ok, some have been revoked, but not everything
  of the very old and obsolete stuff.

  How this reflects to  klibc ?     What I understand of klibc,
  it can track very closely the kernel in question.  Introducing
  new improved syscall to do XYZ obsoliting ABC, whimblam, you
  replace it.  No need to carry code supporting any other version
  of kernel than for what the stuff is made for.
  ("Small is beautifull", and all that...)

  glibc folks are (to an extreme pain) supporting kernels 2.0
  (if not from before) to current bleeding edge, and emulating
  all fancy dancing available with new system services by doing
  some weird gimmicks..

>     Of course, you can provide a custom implementation for
> any one platform, but the idea is to keep as much of the code
> generic as possible...

  Desire to support running of "native UNIX" binaries means
  emulating their syscalls.  Initially Linux ran MINIX binaries,
  then came SCO binaries, and Alpha running some of OSF/1 binaries...

> 	-hpa

/Matti Aarnio