Re: 2.2 projects

[Ulrich Drepper <drepper@cygnus.com>]

Zack Weinberg <zack@rabi.columbia.edu> writes:

> Now it looks like 2.1 is in the can, we should start thinking about what we
> want to do for 2.2.  I already have a short list:

Fair enough.  I've already thought about thinking this a lot.

> - localedef rewrite
> - wide streams

I'm working on both of these an progress is nice.  Actually, this
progress should IMO influence heavily the release schedule.

The point is that currently the glibc is not usable unchanged for
Asian who want to use there locales.  This only means that
incompatible solutions can come up which is something I absolutely
don't want.

Therefore my plan is to release glibc 2.2 as soon as the above two
changes are stable, independent of the other projects.  I have no
problems at all with forking a 2.2 release branch very early so that
work on the other projects can also start right away.

> - build overhaul

Yes, but given the constraints that we certainly don't want to require
a 200MB RAM machine as it would be necessary if we go away for
recursive make calls.

> - new test framework

Hum, I'm not really convinced.  I have to work all the day with
dejagnu and I hate it.  If there are major benefits I can be convinced
but requiring a user to install dejagnu to perform the tests is IMO
not the best solution.  Many problems are found by the tests which
would have catastrophic results if the library would have been
installed.

I must admit I haven't really looked at Zack's rewrite of the code.
If it is still possible to use `make check' as before I'd have no
problems.

> - TLI over sockets, XTI if possible

Fine, if we can get this done.

> - Thomas's pthreads rewrite

Well, this is something we have to talk about in much more details.  A
thread implementation is very system specific in the low-level code.
And I have some ideas on what we should try to implement.  Those who
are with Linux and the libc development for some time (means, 6 years
or more) might remember my initial proposal which was based on the
Mach scheduler activations paper.  I still think this is the by far
most powerful model if implemented correctly.  It combines the
benefits of kernel threads with that of user-level threads.

> and a longer one:
> 
> - OpenBSD extended crypt() [need non-US hacker]

Don't know about this.

> - complete IPv6 support [almost there?]

There is one bigger function missing and certainly the headers will
change more.

> - default to BSD network headers (?)

What do you mean by this?

> - libio for Hurd (needs the new pthreads)
> - more, better documentation

Sure.  Always on my list.  I always appreciate contributions in this area.

> - more test cases (only ~10% of the library is tested right now)
> - better regexp library

Yep, one of my bluesky projects.  I really would like to do this once
there is no urgent change.

> - tighter namespace cleanliness in POSIX mode, XPG if possible

Hhm, there shouldn't be any violations except for missing function
definitions.

We need the missing POSIX real-time extensions (global semaphores,
message queues, timers).  Maybe even all-user-level implementations
though I would very much more like to have kernel support.

> The build work and the new test framework are mine; I'll probably do TLI if
> no one else gets to it.

Great.

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