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>