Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Mar 2003 16:46:31 -0700
From:      Scott Long <scott_long@btc.adaptec.com>
To:        Daniel Eischen <eischen@pcnet1.pcnet.com>
Cc:        arch@freebsd.org
Subject:   Re: 1:1 threading.
Message-ID:  <3E838D57.4050305@btc.adaptec.com>
In-Reply-To: <Pine.GSO.4.10.10303271818110.24399-100000@pcnet1.pcnet.com>
References:  <Pine.GSO.4.10.10303271818110.24399-100000@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote:

> On Thu, 27 Mar 2003, Andrew Gallatin wrote:
>
>
> >Daniel Eischen writes:
> > > On Thu, 27 Mar 2003, Jeff Roberson wrote:
> > >
> > > > On Thu, 27 Mar 2003, Daniel Eischen wrote:
> > > >
> > > > Which means they are likely to change.  I do not want to develop on
> > > > unstable APIs and unstable kernel code.  kern_thr.c is 254 
> lines.  I think
> > > > we can handle a little duplication.  I'm not sure why the 
> objection is so
> > > > strong.
> > >
> > > I don't see kse_create() changing since it takes a
> > > mailbox pointer as an argument and you can theoretically
> > > hang anything off the [versioned] mailbox.
> >
> >According to the 5-stable roadmap at
> >	  http://www.freebsd.org/doc/en/articles/5-roadmap/major-issues.html
> >
> >   KSE kernel and userland components must be functionality complete
> >   by June 2003 in order to be included in the RELENG_5 branch. For
> >   security and stability reasons, if KSE cannot be finished in time
> >   then, by default, all KSE-specific syscalls should be modified to
> >   return ENOSYS and all other KSE-specific interfaces disabled.
>
>
> This sounds like an argument to use the KSE syscalls :-)
> If libthr is based on KSE and it works, then you've accomplished
> the above.
>
The 5-stable roadmap document was written before, and without any
knowledge of, Jeff's work.  The purpose of the above paragraph was
to define a deadline for the threading work to be done.  With the
advent of libthr, there is no longer pressure for the KSE kernel and
userland components to be complete for RELENG_5, so the quoted
paragraph can be relaxed a little bit.  I'm not sure if I would feel
comfortable shipping a release with the KSE syscalls turned on but
no libkse to interact with them, but that can be discussed further.

The bigger picture is that libthr is at the point now that I wanted
libkse to be at in 3 months.  Some may be grumpy and feel that libthr
has subverted libkse, however I'd like to remind everyone that Jon and
Jeff were under no contractual obligation to work on libkse.  Their
work does, however, solve the pressing need for a working threading
library for 5-STABLE.  If someone wants to pick up the torch for
libkse and finish it by the June deadline, I would be thrilled.
Otherwise, I'm happy with libthr for 5-STABLE, and I encourage people
to finish libkse and M:N for 6.0.

As for the arguments of libthr creating new syscalls, I'll point out
that KSE and libkse have not yet run any real-world applications, and
therefore are hard to even consider as 'alpha' quality.  It's foolish
to assume that the KSE interfaces will not change as KSE matures.
If libthr is tied to the current interface, it creates a maintenance
nightmare as the interface changes, especially for the RELENG_5
branch.  I realize that it also creates baggage once libkse is the
default, but that can be solved by deprecating the libthr interfaces
for 6.x and removing them for 7.x.  It's a small price to pay for such
a huge benefit.

Scott



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E838D57.4050305>