Re: [libc-alpha] Re: Wish for 2002 ...

[Jeroen Dekkers <jeroen at dekkers dot cx>]

On Sun, Jan 13, 2002 at 01:12:05AM -0800, Kaz Kylheku wrote:
> On Sun, 13 Jan 2002, Shawn Starr wrote:
> 
> > While I'm not on the mailing list and do use C I think we need to make
> > sure:
> > 
> > We do not isolate ourself from the other UNIX platforms just for sake
> 
> What ``other''? What part of GNU is Not Unix isn't clear? :)
> 
> GNU/Linux us a Unix-like platform, because it makes sense to be that
> right now. Though not nearly as much sense as it did in 1992.

GNU/Hurd isn't a Unix-like platform, but it has a POSIX interface. It
specifically uses glibc for that POSIX interface. Do you know why?
Because else there was no program running on the Hurd. In 1990 it made
sense, but it still makes sense today.

> The only operating system interface standards have come out of the Unix
> world. It makes sense to implement standards and to continue to track them
> where it makes sense. If there is a standard about how to do something,
> it makes sense to do it that way rather than invent your own way of doing
> it. Inventing your own way is counterproductive, and can only be due to
> hidden motives, like getting people to write lots of software to your
> unique interfaces, so that less of that software is available to users
> of other platforms.
> 
> On the other hand, someone's locally developed functions are not
> standards, so it doesn't make sense to implement those, except when
> those functions are proprietary, and some important free software 
> needs them.

And if there is a lot of free software using it, why doesn't it make
sense to implement it?

> You are confusing Unix with some kind of ideology, or ``happy family''
> or something. Get over your stupid nostalgic emotions and start thinking
> rationally.

I think big parts of Unix are broken today, it hasn't changed much
since the mid-1980s, but the hardware has changed and the needs of the
users also.

> > of POSIX standards because then we'll loose in the long run. It would be
> 
> > Why don't we have a libbsd library for non standard functions and keep
> > them out of glibc? Then if they got approved be moved into glibc?
> 
> If there is a program that you desperately want to run, and it is only
> portable to BSD, then install and run BSD. How about that?

You can also hack the needed functionality in your GNU system. Or is
that wrong?
 
> If people want to write code that requires BSD, they are entitled to do
> so. But the world doesn't owe them portability in return, and they
> probably don't expect it! I would hope that people coding for BSD are
> competent enough to *know* when they are making a nonportable program, so
> that when they do so it can only be the case that they don't *care*. When
> the developer of the nonportable program doesn't care, why should the
> GNU/Linux maintainers supply *extra* care to compensate the user for
> that other developer's lack of caring?

But if they like the strlc*() functions for some reason not known to
me (but I'm not going to argue about those reasons) which exist on
their BSD system, why not provide those functions so they can also use
it on their GNU system?
 
> By the way, can you name a BSD-only program that you would you like to
> run on your GNU/Linux system but presently cannot?  Speaking for myself,
> I cannot name such a program.

But I can name programs which use functions which are in the BSD libc
and not in the GNU libc. I don't see a problem in supporting those functions.

> However, in 1990 there was sure lots of free software running on Unix that
> I wanted to be able to run on a free operating system, using commodity
> hardware. BSD hadn't been unencumbered yet; there was no free
> implementation of Unix.

In 2002, there is a lot of free software using BSD functions. We
should support those BSD functions in glibc, as that's the reason why
glibc exist, providing commonly used functions for developers.

> > Is there harm in doing this?
> 
> No harm at all; go ahead and start libbsd. I suspect you will probably
> need some kernel hacking to get every last feature of BSD implemented
> right.  What if the BSD program wants some system call that doesn't
> exist in the Linux kernel, and can't be effectively emulated in libbsd?
> It might make more sense to just emulate BSD at the system call level.
> Then you could just use actual BSD libraries instead of writing them
> from scratch.

Maybe it's better to just split up the big libc in small
libraries. You have then libposix, libstr, lbisd, etc. AFAIK it's
already done at the source level, are reasons why we don't do it in
the binary? I don't have enough knowledge about glibc yet to argue
about it.

Emulating system calls isn't that if you have a good designed system
like the Hurd. I give you a big chance of being able to emulate BSD if
you want to. You can even emulate it on system call level if I'm
right (at least that's what I've read somewhere, but I don't remember
the details, some Hurd hackers on this list could probably tell you
more if you're interested). But it's not worth the trouble, a
recompile against a compatible glibc is much easier.

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects

Attachment: msg00186/pgp00000.pgp
Description: PGP signature