headers
Roland McGrath | 16 Feb 2003 01:10

hurd configure update

I've added a new configure script and trivial shell script in the hurd/
subdir that give some formality to the simple copying needed for populating
a virgin cross compilation setup so you can build libc.  Somebody should
update docs and faqs to describe the bootstrap procedure as:

	1. install mach headers (unchanged)
	2. Run hurd/hurd/configure (works in a separate dir or the srcdir),
	   giving --prefix=/usr/local/i686-gnu or whatever is appropriate
	   for where you want /include/hurd headers installed under.
	3. Run ./install-headers (shell script configure creates)
	4. Now you can build libc with this cross compilation setup

With that done, I've put in Jeff's changes to the main configure script to
be compatible with newer Autoconf versions.  This breaks the old feature of
being able to configure with an incomplete cross compilation tree.  That
should not be required any longer because with the new procedure above,
you never configure the hurd until after you have libc built and installed.

I've also put the generated configure files in the repository, since we
have had consensus on the wisdom of that for a while now.
Permalink | Reply | 0 comments |
headers
Roland McGrath | 16 Feb 2003 04:50

TLS in Hurd glibc

I've added a smidgen of code to libc to enable TLS support on Mach/x86.
If you are not already on top of everything with libc, just build using
--without-tls (I guess it's still the default) and get all other
significant problems addressed before worrying about this.

It's written to try both i386_set_gdt and i386_set_ldt.  The former is
new in oskit-mach.  If compiled with an old mach_i386.defs installed, it
won't try to use i386_set_gdt.  If compiled with new headers, it will
try to use it but fall back to i386_set_ldt if it gets MIG_BAD_ID, which
ought to work with gnumach1.

The --with-tls build compiles, but that's the best I can say.  The goal
after the build without TLS is in decent shape is that the make check
tests in elf/tst-tls* will work in a native hurd build.  Ideally we
should test on both gnumach1 and oskit-mach, and verify (by inspection
in the debugger) that it's using the right mechanisms in both.

The tests aren't all that meaningful until there is a way to have
multiple threads that use TLS data, but making them work is the first
step.

cthreads and Neal's libpthread can easily be modified to use
_dl_allocate_tls so that new threads get set up for TLS.  The simple
thing to do first is just tack on the calls and try some tests of TLS
use, but leave the existing thread data structures untouched.

As soon as TLS is nominally working, I want to switch libc to using
those data structures and the thread register for the hurd threadvars.
Then we can punt all the magic for the single-threaded and signal-thread
cases in that stuff, and keep it simple.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland McGrath | 17 Feb 2003 09:50

futex for Mach?

When the new threads library that became NPTL began to materialize, I had
been envisioning adapting it with a genericized port using user-space
queues and IPC for wakeups.  That is how cthreads works, how Neal's
libpthread works, and how LinuxThreads works.  The NPTL library is quite
different, and relies entirely on Linux's new "futex" system call.

Lately I have been considering the contrary path of implementing the futex
calls for Mach.  There are two kinds of reasons to do this.

The obvious set of reasons boils down to "because Linux does".  That is, we
can port NPTL without a great deal of change and even use the optimized
assembly versions of the synchronization primitives with only slight change.

But the other reasons are that it seems like a useful facility.  The
clincher for me is that it makes process-shared pthread_mutex's in shared
mmap regions Just Work with no extra thought.  It's sufficiently clumsy in
Mach to be well nigh infeasible to do an inter-process mutex implementation
with real blocking (i.e. not just spin locks), since it has to be by IPC
and it require big hair to have a global identifier in the shared data
structure.  There are other cases of blocking, like sigsuspend/sigwait,
where I think that futex can be a more natural and convenient (and probably
efficient) way to implement it than using IPC as it has to now.

The futex inteface is a simple and light-weight kernel-provided blocking
and wakeup facility that associates a wait queue with any word in memory
without prior setup.  Any two threads sharing any one page can synchronize
with each other just by referring to an address within that page in futex
calls.  (Hence NPTL's mutex and cond implementions done purely with futex
can be shared with mmap and just work.)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Marcus Brinkmann | 17 Feb 2003 13:40
Picon
Favicon

Re: futex for Mach?

On Mon, Feb 17, 2003 at 12:50:41AM -0800, Roland McGrath wrote:
> Lately I have been considering the contrary path of implementing the futex
> calls for Mach.  There are two kinds of reasons to do this.

> What do people think?

You laid out your reasons very well, and it sounds interesting enough, in
particular in terms of simplicity.

I am worried about L4, though.  If that feature is desirable in Linux and in
Mach, it is probably desirable in every other kernel as well.  Maybe there
is some L4 specific feature that saves us here, or maybe we can implement
the generic alternative you mentioned on L4.  Or maybe we can even extend L4
by a futex system call for this purpose (although I'd think that such an
extension has not the slightest chance to become official).

In other words:  We are adding a new requirement to the underlying kernel,
instead working with the minimal set of primitives.

That doesn't mean it's not the easiest and best way to just do that here and
now, just a general observation.  L4 is radically different enough so that
it does not matter if this question is postponed.  I guess it depends on how
much work either solution is and how far L4 is away.

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus <at> gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Roland McGrath | 18 Feb 2003 03:25

Re: futex for Mach?

> I am worried about L4, though.

I don't think anything is lost by not worrying about L4 now.  If a
different kind of port is desireable later on whatever kernel, we can do it
later.  If later we want a port similar to Neal's libpthread, we can reuse
some of that code.  

> In other words:  We are adding a new requirement to the underlying kernel,
> instead working with the minimal set of primitives.

No, this is an implementation detail of one of the existing requirements,
which is "libpthread implementation appropriate for the underlying kernel".

The only potentially wasted effort is that of adding futex to Mach and
working on NPTL.  The user-level stuff for using new Mach futex interfaces
per se will be small, and the other stuff that needs to be done with NPTL
and glibc is the tight integration with glibc and revamp of some hurdish
glibc innards that we need eventually to do one way or the other.

As to the kernel work, I think I can do that pretty quickly especially if
we are not worried to begin with about it being especially fast.
Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 18 Feb 2003 03:43
Picon
Favicon

Re: futex for Mach?

On Mon, Feb 17, 2003 at 09:25:38PM -0500, Roland McGrath wrote:
> > In other words:  We are adding a new requirement to the underlying kernel,
> > instead working with the minimal set of primitives.
> 
> No, this is an implementation detail of one of the existing requirements,
> which is "libpthread implementation appropriate for the underlying kernel".

Mmh, ok.  That is correct, it is limited to pthread and not exposed beyond
that.

> The only potentially wasted effort is that of adding futex to Mach and
> working on NPTL.  The user-level stuff for using new Mach futex interfaces
> per se will be small, and the other stuff that needs to be done with NPTL
> and glibc is the tight integration with glibc and revamp of some hurdish
> glibc innards that we need eventually to do one way or the other.
> 
> As to the kernel work, I think I can do that pretty quickly especially if
> we are not worried to begin with about it being especially fast.

Ok, that sounds good to me.

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus <at> gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann <at> ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland McGrath | 22 Feb 2003 09:45

gnumach-dev

What's the current story with gnumach debian packages?
Where is the source package that matches gnumach-dev 2:1.90.20020731-1?
debian/changelog in the oskit-mach/mainline gnumach2 cvs has nothing newer
than the gnumach-1-branch.

We need a new gnumach-dev package with current mainline's mach_i386.defs.
I don't see why these shouldn't be cut direclty from the mainline cvs and
with its debian/ files updated accordingly in cvs.

And for the binary packages, what's the story with gnumach vs gnumach1?
There seems to be a gnumach package in the debian archive and an identical
version packaged as gnumach1 on alpha.  What's the plan exactly?  Seems to
me gnumach1 ought to go into debian proper, as its the current stable
choice.  If oskit-mach works at all, we should have an experimental gnumach
binary package people can try instead of/in addition to gnumach1.  Perhaps
they should not both use the same file name in /boot.
Permalink | Reply | 0 comments |
headers
sid ganjal | 23 Feb 2003 10:14
Picon

: Contents of Hurd-devel-readers digest..."


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus
Permalink | Reply | 0 comments |

Gmane