Robert Watson posted another FreeBSD 5.2 "Open Issues" list, still containing 18 "must resolve issues" before 5.2 will be released [forum]. A discussion followed about one of the items, "KSE support for alpha", owned by Marcel Moolenaar. Marcel indicated that the implementation would happen, however suggesting that the Alpha architecture should be demoted to a 'Tier 2 Developmental Architecture' now reaching toward its end of life. Wilko Bulte went even further, saying, "In my book sparc64 is also with one foot in the grave. As is Sun itself. If we want to be future proof ia64 and amd64 are the only viable architectures. The rest are just interesting passtimes.."
Poul-Henning Kamp, member of the FreeBSD core team since 1994 and author of the GEOM stackable BIO subsystem [story], defended Sparc64 as useful in having another byte order to "keep our code honest". He goes on to explain:
"Alpha has sort of outlived its role as our 'token architecture', 'pc98' doesn't qualify due to inbreeding, 'amd64' doesn't qualify due to nepotism, 'ia64' is not yet there. That leaves us only 'sparc64' as candidate for that job. Therefore I would like to keep the sparc64 port alive, even at a pretty high cost in effort."
From: Robert Watson [email blocked]
To: current
Subject: 5.2-RELEASE TODO
Date: Mon, 29 Sep 2003 10:00:18 -0400 (EDT)
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list.
The live version of this list is available at:
http://www.FreeBSD.org/releases/5.2R/todo.html
Automated mailing of this list will continue through the release of
FreeBSD 5.2.
FreeBSD 5.2 Open Issues
Open Issues
This is a list of open issues that need to be resolved for FreeBSD 5.2. If
you have any updates for this list, please e-mail [email blocked].
Must Resolve Issues for 5.2-RELEASE
+------------------------------------------------------------------------+
| Issue | Status | Responsible | Description |
|---------------------+-----------+-----------------+--------------------|
| | | | KSE M:N threading |
| | | | support is |
| | | | reaching |
| | | | experimental yet |
| | | Julian | usable status on |
| Production-quality | In | Elischer, David | i386 for |
| M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N |
| | | Eischen | threading should |
| | | | be productionable |
| | | | and usable on all |
| | | | platforms by |
| | | | 5.2-RELEASE. |
|---------------------+-----------+-----------------+--------------------|
| | | | Kernel bits are |
| | | | implemented but |
| KSE support for | In | | untested. Userland |
| sparc64 | progress | Jake Burkholder | bits are not |
| | | | implemented. |
| | | | Required for |
| | | | 5.2-RELEASE. |
|---------------------+-----------+-----------------+--------------------|
| | | | Kernel and |
| KSE support for | | Marcel | userland bits |
| ia64 | Complete. | Moolenaar | implemented but |
| | | | unstable. Required |
| | | | for 5.2-RELEASE. |
|---------------------+-----------+-----------------+--------------------|
| | | | Userland bits |
| | | | implemented, |
| KSE support for | In | Marcel | kernel bits not |
| alpha | progress. | Moolenaar | implemented. |
| | | | Required for |
| | | | 5.2-RELEASE. |
|---------------------+-----------+-----------------+--------------------|
| | | | Kris Kennaway |
| | | | reports high |
| | | | instability of |
| | | | 5-CURRENT on ia64 |
| | | | machines, such as |
| ia64 stability | In | Marcel | the pluto* |
| | Progress | Moolenaar | machines. These |
| | | | problems need to |
| | | | be fixed in order |
| | | | to get a |
| | | | successful package |
| | | | build. |
|---------------------+-----------+-----------------+--------------------|
| | | | A reworking of the |
| | | | sio driver is |
| | | | needed to support |
| | | | serial terminal |
| | | Marcel | devices on sparc64 |
| New serial UART | In | Moolenaar, | and ia64 |
| framework | progress | Warner Losh | platforms, among |
| | | | others. This is |
| | | | also an enabler |
| | | | for syscons |
| | | | support on |
| | | | sparc64. |
|---------------------+-----------+-----------------+--------------------|
| | | | FAST_IPSEC |
| | | | currently cannot |
| | | | be used directly |
| | | | with the KAME IPv6 |
| | | | implementation, |
| | | | requiring an |
| | | | additional level |
| | | | of IP tunnel |
| | | | indirection to |
| | | | protect IPv6 |
| | | | packets when using |
| | | | hardware crypto |
| FAST_IPSEC and KAME | | | acceleration. This |
| compatibility | -- | -- | issue must be |
| | | | resolved so that |
| | | | the two services |
| | | | may more easily be |
| | | | used together. |
| | | | Among other |
| | | | things, this will |
| | | | require a careful |
| | | | review of the |
| | | | handling of mbuf |
| | | | header copying and |
| | | | m_tag support in |
| | | | the KAME IPv6 |
| | | | code. |
|---------------------+-----------+-----------------+--------------------|
| | | | The FreeBSD KAME |
| | | | IPv6 code is now |
| | | | substantially |
| | | | dated with respect |
| | | | to the KAME vendor |
| KAME | In | Hajimu UMEMOTO | source. The |
| Synchronization | progress | | FreeBSD Project |
| | | | needs to take |
| | | | initiative in |
| | | | driving the merge |
| | | | of new bug fixes, |
| | | | features, et al. |
|---------------------+-----------+-----------------+--------------------|
| | | | Almost all process |
| | | | debugging tools |
| | | | have been updated |
| | | | to use non-procfs |
| | | | kernel primitives, |
| | | | with the exception |
| | | | of truss(1). As |
| | | | procfs is |
| | | | considered |
| | | | deprecated due to |
| | | | its inherent |
| truss support for | In | Robert Drehmel | security risks, it |
| ptrace | progress | | is highly |
| | | | desirable to |
| | | | update truss to |
| | | | operate in a |
| | | | post-procfs world. |
| | | | Dag-Erling |
| | | | Smorgrav had |
| | | | prototype patches; |
| | | | Robert Drehmel is |
| | | | developing and |
| | | | testing patches |
| | | | now. |
|---------------------+-----------+-----------------+--------------------|
| | | | Apple's Darwin |
| | | | operating system |
| | | | has fairly |
| | | | extensive |
| Merge of Darwin | | | improvements to |
| msdosfs, other | -- | -- | msdosfs and other |
| fixes | | | kernel services; |
| | | | these fixes must |
| | | | be reviewed and |
| | | | merged to the |
| | | | FreeBSD tree. |
|---------------------+-----------+-----------------+--------------------|
| | | | Many systems |
| | | | supporting |
| | | | POSIX.1e ACLs |
| | | | permit a minor |
| | | | violation to that |
| | | | specification, in |
| | | | which the ACL_MASK |
| | | | entry overrides |
| ACL_MASK override | In | | the umask, rather |
| of umask support in | progress | Robert Watson | than being |
| UFS | | | intersected with |
| | | | it. The resulting |
| | | | semantics can be |
| | | | useful in |
| | | | group-oriented |
| | | | environments, and |
| | | | as such would be |
| | | | very helpful on |
| | | | FreeBSD. |
|---------------------+-----------+-----------------+--------------------|
| | | | Significant parts |
| | | | of the network |
| | | | stack (especially |
| | | | IPv4 and IPv6) now |
| | | | have fine-grained |
| | | | locking of their |
| | | | data structures. |
| | | | However, it is not |
| | | | yet possible for |
| | | | the netisr threads |
| | | | to run without |
| | | | Giant, due to |
| Fine-grained | | | dependencies on |
| network stack | In | Jeffrey Hsu, | sockets, routing, |
| locking without | progress | Seigo Tanimura, | etc. A 5.2-RELEASE |
| Giant | | Sam Leffler | goal is to have |
| | | | the network stack |
| | | | running largely |
| | | | without Giant, |
| | | | which should |
| | | | substantially |
| | | | improve |
| | | | performance of the |
| | | | stack, as well as |
| | | | other system |
| | | | components by |
| | | | reducing |
| | | | contention on |
| | | | Giant. |
|---------------------+-----------+-----------------+--------------------|
| | | | Productionable |
| | | | support for the |
| | | | AMD64 platform. |
| | | | Currently, AMD64 |
| | | | runs fully in |
| | | | 32-bit emulation |
| Tier-1 Support for | In | Peter Wemm, | mode, and boots to |
| AMD64 Hammer | progress | David O'Brien | single-user in |
| | | | 64-bit mode. We |
| | | | expect full |
| | | | production support |
| | | | for the AMD64 |
| | | | architecture in |
| | | | 5.2-RELEASE. |
|---------------------+-----------+-----------------+--------------------|
| | | | Kernel modules are |
| | | | currently built |
| | | | independently from |
| | | | a kernel |
| | | | configuration, and |
| | | | independently from |
| | | | one another, |
| | | | resulting in |
| | | | substantially |
| | | | redundant |
| | | | compilation of |
| | | | objects, as well |
| | | | as the inability |
| | | | to easily manage |
| | | | compile-time |
| | | | options for kernel |
| | | | objects (such as |
| | | | MAC, PAE, etc) |
| Revised kld build | -- | -- | that may require |
| infrastructure | | | conditional |
| | | | compilation in the |
| | | | kernel modules. In |
| | | | order to improve |
| | | | build performance |
| | | | and better support |
| | | | options of this |
| | | | sort, the KLD |
| | | | build |
| | | | infrastructure |
| | | | needs to be |
| | | | revamped. Peter |
| | | | Wemm has done some |
| | | | initial |
| | | | prototyping, and |
| | | | should be |
| | | | contacted before |
| | | | starting on this |
| | | | work. |
|---------------------+-----------+-----------------+--------------------|
| | | | Currently, there |
| | | | are two classes of |
| | | | interrupt handlers |
| | | | in 5.x: fast |
| | | | interrupt handlers |
| | | | which run entirely |
| | | | in interrupt |
| | | | context, and |
| | | | heavy-weight |
| | | | handlers which |
| | | | execute in a |
| | | | full-weight kernel |
| | | | interrupt thread. |
| | | | It is possible to |
| | | | optimize interrupt |
| | | | thread context |
| | | | management such |
| | | | that a |
| | | | light-weight |
| | | | context switch is |
| | | | performed to begin |
| | | | execution of the |
| | | | interrupt thread |
| | | | in the handler |
| | | | context, and only |
| Light-weight | | | when a full-weight |
| interrupt threads, | -- | -- | context is |
| context switches | | | required (such as |
| | | | sleeping on a |
| | | | lock) is that cost |
| | | | required. This |
| | | | optimization |
| | | | should |
| | | | substantially |
| | | | improve interrupt |
| | | | latency. There are |
| | | | also additional |
| | | | kernel thread |
| | | | context switch |
| | | | optimizations that |
| | | | can be made to |
| | | | improve the |
| | | | performance of |
| | | | thread workers in |
| | | | the kernel, such |
| | | | as found in the |
| | | | network stack, |
| | | | crypto worker |
| | | | threads, and GEOM. |
| | | | Bosko Milekic has |
| | | | done substantial |
| | | | prototyping work, |
| | | | and should be |
| | | | coordinated with. |
|---------------------+-----------+-----------------+--------------------|
| | | | The existing APIC |
| | | | interrupt code |
| | | | does not support |
| Complete the APIC | | | PCI interrupt |
| PCI interrupt | In | John Baldwin | routing properly. |
| routing support | progress | | As a result, PCI |
| | | | interrupts cannot |
| | | | be routed either |
| | | | via ACPI or across |
| | | | PCI-PCI bridges. |
|---------------------+-----------+-----------------+--------------------|
| | | | Currently, gbde |
| | | | must be manually |
| | | | configured at |
| | | | run-time each time |
| | | | an encrypted disk |
| | | | device is mounted. |
| | | | This prevents easy |
| Run-time | | | integration into |
| autoconfiguration | | | /etc/fstab and |
| of GBDE and related | -- | -- | easy automated |
| transforms | | | deployment. |
| | | | Improved |
| | | | integration with |
| | | | the configuration, |
| | | | mounting, and boot |
| | | | process is |
| | | | required to make |
| | | | this feature more |
| | | | easily accessible. |
|---------------------+-----------+-----------------+--------------------|
| | | | Brian Feldman has |
| | | | submitted patches |
| | | | to improve the |
| | | | consistency of the |
| | | | pathnames passed |
| | | | into the MAC |
| MAC Framework devfs | In | Robert Watson | Framework devfs |
| path fixes | progress | | labeling entry |
| | | | points. These |
| | | | patches need to be |
| | | | thoroughly |
| | | | reviewed and |
| | | | tested, then |
| | | | merged. |
|---------------------+-----------+-----------------+--------------------|
| | | | A process cannot |
| | | | be interrupted |
| | | | while waiting on a |
| | | | lock. Fixing this |
| rpc.lockd(8) | In | Robert Watson | requires that the |
| stability | progress | | rpc code be taught |
| | | | how to deal with |
| | | | lock cancellation |
| | | | and interruption |
| | | | events. |
+------------------------------------------------------------------------+
Desired Features for 5.2-RELEASE
+------------------------------------------------------------------------+
| Issue | Status | Responsible | Description |
|---------------+-------------+----------------+-------------------------|
| | | | Truss appears to |
| | | | contain a race |
| | | | condition during the |
| | | | start-up of debugging, |
| | | | which can result in |
| | | | truss failing to attach |
| | | | to the process before |
| | | | it exits. The symptom |
| | | | is that truss reports |
| | | | that it cannot open the |
| | | | procfs node supporting |
| | | | the process being |
| Race | | | debugged. A bug also |
| conditions in | Errata | Robert Drehmel | appears to exist where |
| truss | candidate | | in truss will hang if |
| | | | execve() returns |
| | | | ENOENT. A further race |
| | | | appears to exist in |
| | | | which truss will return |
| | | | "PIOCWAIT: Input/output |
| | | | error" occasionally on |
| | | | startup. The fix for |
| | | | this sufficiently |
| | | | changes process |
| | | | execution handling that |
| | | | we will defer the fix |
| | | | to post-5.0 and |
| | | | consider this errata. |
|---------------+-------------+----------------+-------------------------|
| gdb -k | | | gdb -k doesn't work on |
| support for | -- | Mark Peek | alpha |
| alpha | | | |
|---------------+-------------+----------------+-------------------------|
| | | | Currently, MAC |
| | | | protections are |
| | | | enforced only on |
| | | | locally originated file |
| | | | system operations |
| | | | (VOPs), and not on RPCs |
| | | | generated via the NFS |
| MAC support | | | server. Improvements in |
| for NFS | -- | Robert Watson | NFS server credential |
| Server | | | handling are required |
| | | | to correct this |
| | | | problem, as well as the |
| | | | introduction of new |
| | | | entry points to |
| | | | properly label NFS |
| | | | credentials and perform |
| | | | enforcement properly. |
|---------------+-------------+----------------+-------------------------|
| | | | All PCI drivers must |
| | | | use busdma for DMA; no |
| busdma in all | | | use of vtophys() will |
| PCI drivers | -- | -- | be permitted for any |
| | | | recent device driver. |
| | | | ISA drivers may be |
| | | | exempt. |
|---------------+-------------+----------------+-------------------------|
| | | | With improved support |
| | | | for threading |
| | | | primitives, support is |
| | | | now required to ease |
| GDB thread | -- | -- | debugging of threaded |
| support | | | applications. Ideally, |
| | | | this support will work |
| | | | for both libthr and |
| | | | libkse threading |
| | | | models. |
|---------------+-------------+----------------+-------------------------|
| | | | Prebinding reduces |
| | | | executable startup time |
| | | | by lowering the expense |
| | | | of symbol lookup, |
| | | | binding and relocation. |
| | | | This is accomplished by |
| | | | a prebinding data file |
| | | | or ELF segment that |
| | | | contains intermediate |
| | | | lookup results allowing |
| | | | fast symbol binding and |
| | | | relocation, provided |
| Per object | | | that dependent objects |
| ELF | In progress | Matthew Dodd | remain unchanged since |
| Prebinding | | | the prebinding |
| support | | | information was |
| | | | generated. |
| | | | |
| | | | The benefits of |
| | | | prebinding are realized |
| | | | when running |
| | | | executables that use a |
| | | | large (>10) number of |
| | | | shared libraries. C++ |
| | | | applications also |
| | | | benefit as they contain |
| | | | a large number of |
| | | | relocations. |
+------------------------------------------------------------------------+
Documentation items that must be resolved for 5.2
+------------------------------------------------------------------------+
| Issue | Status | Responsible | Description |
|---------------+--------+---------------+-------------------------------|
| Bluetooth | | | It'd be nice to have some |
| documentation | -- | Pav Lucistnik | Bluetooth documentation for |
| | | | the Handbook. |
+------------------------------------------------------------------------+
Testing focuses for 5.2-RELEASE
+------------------------------------------------------------------------+
| Issue | Status | Responsible | Description |
|---------------+----------+----------------+----------------------------|
| | | | New ATA model has arrived. |
| ATA driver | | | Much testing is needed to |
| structural | Complete | So/ren Schmidt | ensure no regressions. |
| improvements, | | | ATAPI-CAM seems especially |
| MPsafety | | | fragile, more testing is |
| | | | encouraged. |
+------------------------------------------------------------------------+
----------------------------------------------------------------------
home | contact | legal | (c) 1995-2003 The FreeBSD Project.
All rights reserved.
Last modified: 2003/09/01 06:09:17
From: Daniel Eischen [email blocked]
Subject: Re: 5.2-RELEASE TODO
Date: Mon, 29 Sep 2003 14:05:16 -0400 (EDT)
On Mon, 29 Sep 2003, Robert Watson wrote:
> |---------------------+-----------+-----------------+--------------------|
> | | | | Userland bits |
> | | | | implemented, |
> | KSE support for | In | Marcel | kernel bits not |
> | alpha | progress. | Moolenaar | implemented. |
> | | | | Required for |
> | | | | 5.2-RELEASE. |
You should probably remove Marcel from this item. This task needs
another volunteer.
--
Dan Eischen
From: Wilko Bulte [email blocked]
Subject: Re: 5.2-RELEASE TODO
Date: Mon, 29 Sep 2003 20:07:32 +0200
On Mon, Sep 29, 2003 at 02:05:16PM -0400, Daniel Eischen wrote:
>
> You should probably remove Marcel from this item. This task needs
> another volunteer.
Recently Marcel noted to me he was planning to engage on this one. I have
offered him help for testing.
--
| / o / /_ _ [email blocked]
|/|/ / / /( (_) Bulte
From: Marcel Moolenaar [email blocked]
Subject: Re: 5.2-RELEASE TODO
Date: Mon, 29 Sep 2003 12:19:30 -0700
On Mon, Sep 29, 2003 at 08:07:32PM +0200, Wilko Bulte wrote:
> >
> > You should probably remove Marcel from this item. This task needs
> > another volunteer.
>
> Recently Marcel noted to me he was planning to engage on this one. I have
> offered him help for testing.
The deal is this (if you find your way between the parenthesis):
I talked to Wilko prior to the DevSummit and told him that since it
was on my plate (because I stupidly made some commits to get things
rolling; which it did, but not much more than rolling on my plate :-)
and support is almost finished (I looked at it this weekend and it
appears that upcalls work, there's probably something wrong with the
context save/restore code) and I needed to fix ia64 as which (already
done) I likely would fix Alpha in one big swoop.
At the DevSummit we failed to reach agreement that alpha should be
dropped to a tier 2 platform, but we did acknowledge that alpha needs
developers pronto. There it was also agreed that I would enter a
holding pattern (which roughly boils down to me circling between home,
work and Starbucks) until either someone fixes KSE or my weakness
shows and I do it anyway (the fact that I looked at it this weekend
means that I was pretty close to folding -- I made it to Starbucks
just in time).
I also mentioned recently (in the last couple of days) that we should
worry more about sparc64 than alpha. Simply because I think alpha is
on it's way down and should already be a tier 2 platform and sparc64
is still on its way up ... sort of.
--
Marcel Moolenaar USPA: A-39004 [email blocked]
From: Wilko Bulte [email blocked]
Subject: Re: 5.2-RELEASE TODO
Date: Mon, 29 Sep 2003 21:35:16 +0200
On Mon, Sep 29, 2003 at 12:19:30PM -0700, Marcel Moolenaar wrote:
> At the DevSummit we failed to reach agreement that alpha should be
> dropped to a tier 2 platform, but we did acknowledge that alpha needs
> developers pronto. There it was also agreed that I would enter a
> holding pattern (which roughly boils down to me circling between home,
> work and Starbucks) until either someone fixes KSE or my weakness
> shows and I do it anyway (the fact that I looked at it this weekend
> means that I was pretty close to folding -- I made it to Starbucks
> just in time).
You get red hair from too much coffee anyway :-) :-)
> I also mentioned recently (in the last couple of days) that we should
> worry more about sparc64 than alpha. Simply because I think alpha is
> on it's way down and should already be a tier 2 platform and sparc64
> is still on its way up ... sort of.
In my book sparc64 is also with one foot in the grave. As is Sun
itself.
If we want to be future proof ia64 and amd64 are the only viable
architectures. The rest are just interesting passtimes..
--
| / o / /_ _ [email blocked]
|/|/ / / /( (_) Bulte
From: Dan Nelson [email blocked]
Subject: Re: 5.2-RELEASE TODO
Date: Mon, 29 Sep 2003 14:53:04 -0500
In the last episode (Sep 29), Wilko Bulte said:
>
> In my book sparc64 is also with one foot in the grave. As is Sun
> itself.
Fujitsu makes sparc-compatible CPUs, too, so it'll be harder to kill
the entire architecture like HP did with the Alpha.
--
Dan Nelson
[email blocked]
From: Poul-Henning Kamp [email blocked]
Subject: Re: 5.2-RELEASE TODO
Date: Mon, 29 Sep 2003 22:04:47 +0200
In message <20030929195304.GA74320@dan.emsphone.com>, Dan Nelson writes:
>> In my book sparc64 is also with one foot in the grave. As is Sun
>> itself.
>
>Fujitsu makes sparc-compatible CPUs, too, so it'll be harder to kill
>the entire architecture like HP did with the Alpha.
Having at least on architecture with the other byte order helps
keep our code honest. I also think that VM afflicted people tend
to think that it is a good idea to have another model in order to
keep MI separated properly from MD.
Alpha has sort of outlived its role as our "token architecture",
"pc98" doesn't qualify due to inbreeding, "amd64" doesn't qualify
due to nepotism, "ia64" is not yet there. That leaves us only
"sparc64" as candidate for that job.
Therefore I would like to keep the sparc64 port alive, even at a
pretty high cost in effort.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[email blocked] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
