253 lines
9.3 KiB
Plaintext
253 lines
9.3 KiB
Plaintext
# $NetBSD: ROADMAP,v 1.3 2005/11/11 06:09:57 briggs Exp $
|
|
|
|
A high-level roadmap for NetBSD
|
|
|
|
This file contains a general map of where we would like to take
|
|
NetBSD over the next N years. It is not highly detailed or overly
|
|
specific about each item. There are several different "TODO" files
|
|
and "NetBSD Projects" lists in various places that contain some
|
|
more detailed plans. This is the framework in which those projects
|
|
and plans are expected to fit.
|
|
|
|
As this is a volunteer project, there are no specific dates beside
|
|
these items. These items may or may not get picked up in any order,
|
|
and the roadmap may change as technologies and perceived needs
|
|
change.
|
|
|
|
The roadmap, of course, is constructed in the context of the
|
|
Project's (broad) goals:
|
|
|
|
* clean design * stable * fast
|
|
* clean licensing * portable * interoperable
|
|
* conformant * commercial-ready * research-ready
|
|
* hobby-ready
|
|
|
|
In general, we are headed for:
|
|
|
|
* "State of the art" tools (current (and stable) GNU tools,
|
|
addition of Solaris's dtrace or similar functionality, kernel
|
|
core dumps on all platforms and post-mortem analysis tools,
|
|
performance analysis tools with support for hardware assists
|
|
like PMCs)
|
|
|
|
* Support for all devices without encumbered code
|
|
|
|
* Managed growth of the base system
|
|
|
|
* Minimal GPL / LGPL code in the base system
|
|
|
|
* Maximal performance without compromising portability
|
|
|
|
* "State of the art" technology in the kernel and userland
|
|
|
|
* No bugs, no security vulnerabilities
|
|
|
|
* In combination with pkgsrc, a complete system for a variety
|
|
of users, administrators, and researchers: desktops, embedded
|
|
devices, servers, workstations, and portables
|
|
|
|
This is, by no means, a comprehensive list, and purposefully aggressive.
|
|
One of the many challenges will be to achieve excellence in each arena
|
|
we tackle and not settle for being a "jack of all trades, master of none."
|
|
|
|
The following, more specific, items are divided into rough categories:
|
|
1. Platform independent kernel
|
|
2. Platform independent userland
|
|
3. Platform dependent kernel
|
|
4. Platform dependent userland
|
|
5. Other
|
|
|
|
If you'd like to take on a project, please record your name/email,
|
|
the date that you're claiming a project (or part of a project--if
|
|
a part, please specify the part), and an expected completion date.
|
|
This will hopefully avoid both duplication of effort and too many
|
|
or too-extended stalls.
|
|
|
|
1. Platform independent kernel
|
|
==============================
|
|
aa. Modular scheduler supporting CPU affinity and some soft RT features.
|
|
The BSD scheduler is good for a wide variety of operating conditions,
|
|
but some applications really want some soft real-time capabilities and
|
|
multi-processor systems could benefit from taking processor affinity
|
|
into account (including support for HT CPUs).
|
|
|
|
ab. Reduction of the giant lock
|
|
There are several proposals for the best way forward on this, but
|
|
we really need a couple of people with time to step forward and
|
|
lead us here.
|
|
|
|
ac. Expansion of wedge support
|
|
Complete the development of wedges and retire disklabels except
|
|
where needed for compatibility.
|
|
|
|
ad. Volume management
|
|
Allow us to grow, shrink, and move partitions (and, where possible,
|
|
filesystems).
|
|
|
|
ae. High-performance, maybe log-based, journalled fs w/ snapshot support
|
|
Addition of logs, journals, and snapshots to FFS is a lot, another
|
|
filesystem could be cleaner and faster.
|
|
|
|
af. Expansion of ieee1394 support
|
|
Where possible, fully support DV, disk, and network devices.
|
|
|
|
ag. Generic device hotplug support
|
|
Support hotplug of all devices and busses that support it. This
|
|
should be divided into subcategories and does cross over some into
|
|
platform-dependent areas. SATA, SCSI, FC, USB, Firewire,
|
|
PCI (PCI-X, and PCI-Express), etc. There is some rudimentary
|
|
support present, but it is far from comprehensive.
|
|
|
|
ah. Suspend and resume support
|
|
We should be able to fully utilize suspend and resume on PCs, macppc,
|
|
and anyone else who supports it in hardware (sparc, hpcsh, hpcarm, etc).
|
|
|
|
ai. Complete support for LWPs
|
|
There are still vestiges of the kernel that predate LWPification
|
|
and should be updated. [ What other than ktrace? ]
|
|
|
|
aj. PTHREAD_CONCURRENCY > 1 support
|
|
A single process that uses threads should be able to reliably
|
|
utilize more than one CPU.
|
|
|
|
ak. AIO support
|
|
POSIX aio_*() with full support for Asynchronous I/O (AIO) in the
|
|
kernel.
|
|
|
|
al. Modern parallel port support
|
|
Complete support for bidirectional and "advanced" functionality
|
|
from parallel ports.
|
|
|
|
am. NFSv4
|
|
Bring our NFS up to current standards.
|
|
|
|
an. Update the locking mechanisms in the kernel
|
|
This requires some platform support. A good bit of work is on the
|
|
now-archaic "newlock" branch. It requires some overhaul of
|
|
cpu_switch/scheduler so that mutex_*(9) and ltsleep(9) can interlock.
|
|
|
|
ao. Review TCP/IP developments
|
|
Look into RFC3168 (ECN, http://www.icir.org/floyd/ecn.html) and
|
|
other "recent" and current TCP/IP research. Adapt our stack to the
|
|
more modern world.
|
|
|
|
ap. Kernel linker (ala FreeBSD's kld)
|
|
|
|
aq. CARP/VRRP
|
|
Functionality is great, but there might be some concern here over
|
|
Cisco patents.
|
|
|
|
ar. UDF filesystem support
|
|
OpenBSD has recently added this.
|
|
|
|
as. RAIDFrame support for 3-way RAID 1
|
|
|
|
at. RAIDFrame support for RAID 6
|
|
|
|
au. More modern drivers
|
|
We lack support for a number of more modern devices (PCI-Express,
|
|
RAID cards, etc.) that are supported on other open source OSes.
|
|
|
|
av. iSCSI initiator support
|
|
We should be able to utilize iSCSI volumes.
|
|
|
|
aw. Run-time changable limits to SysV IPC
|
|
Some of the limits for SysV IPC are hardcoded in the kernel
|
|
configuration--these should be changable via sysctl.
|
|
|
|
2. Platform independent userland
|
|
================================
|
|
aa. Keep up with the X world
|
|
If we are moving to an X.org base, we need to move forward with that
|
|
and keep up to date. This will require some platform-specific work,
|
|
but is largely platform-independent, and involves making X.org cross-
|
|
buildable.
|
|
|
|
ab. Reentrant libraries
|
|
Make sure that all libraries are re-entrant and usable for threaded
|
|
applications.
|
|
|
|
ac. gcc updates
|
|
This requires some work to rework the gcc4 builds to work with BSD
|
|
make(1) or update BSD make(1) or consider the unthinkable.
|
|
|
|
ad. gdb updates
|
|
|
|
ae. binutils updates
|
|
Probably go along with gdb updates.
|
|
|
|
af. Better post-mortem debugging tools
|
|
It would be useful to have something between ps/*stat/etc. and
|
|
gdb with a core file. Something, perhaps, like SysV(?) crash(8).
|
|
|
|
ag. Better 802.11 utilities and support
|
|
To truly support mobile users, we need better support for scanning
|
|
for base stations and affiliating with them.
|
|
|
|
ah. Internationalization
|
|
Citrus, wide-char curses (SoC integration?), collation, localized
|
|
printf with positional parameter support, time & currency
|
|
support, etc. NetBSD has a global user and developer base and
|
|
our i18n support should reflect that.
|
|
|
|
ai. System packages
|
|
In some fashion, we need to support system packages. This is at
|
|
least to allow for sane binary audits and binary patches.
|
|
|
|
aj. Provide support for binary packages in install
|
|
We should have an integrated install that can install a desktop as
|
|
functional as other free operating systems. Without sacrificing
|
|
the quick and clean basic installs that we have now. An extension
|
|
of sysinst might fit the bill. Or a tool that's both invoked by
|
|
sysinst and available on a running system.
|
|
|
|
ak. Native signing/privacy software
|
|
This could be BPG (from SoC) or openpgp-sdk.
|
|
|
|
al. Userland version identification
|
|
What binaries are installed? Who really knows? This relates at
|
|
least somewhat to (ai).
|
|
|
|
3. Platform dependent kernel
|
|
============================
|
|
aa. Move evb ports to evb* if they're not already there (sandpoint)
|
|
The existing evb* ports are kind of catch-all ports for eval boards.
|
|
Some of the existing non-evb* ports really belong in the evb* category.
|
|
|
|
ab. m68k ports need to share more code
|
|
Some progress has been made here in recent years, but there is more
|
|
work to be done.
|
|
|
|
ac. Kernel core dump support for all platforms
|
|
Some platforms (PowerPC ports, ARM ports, etc.) don't have full
|
|
support for kernel core dumps and post-mortem debugging through
|
|
libkvm. This should be updated.
|
|
|
|
ad. NDIS
|
|
Support for binary network drivers on x86 platforms.
|
|
|
|
4. Platform dependent userland
|
|
==============================
|
|
ab. m68k should be able to share sets
|
|
Some progress has been made here in recent years, but there is more
|
|
work to be done.
|
|
|
|
5. Other
|
|
========
|
|
aa. More and better regression tests
|
|
The suite of tests that we have now is limited. We should expand
|
|
these and provide systems (or manage a volunteer pool?) to run the
|
|
tests on -current and release branches on a variety of platforms.
|
|
( Perhaps virtualize some with qemu or similar? )
|
|
|
|
ab. Native Java on multiple platforms
|
|
Getting i386, amd64, sparc64, and PowerPC would be a good start,
|
|
although PowerPC will require more work. We have the go-ahead,
|
|
but we need the people to work on it.
|
|
|
|
ac. Power control framework
|
|
Related to suspend/resume support, we should have some framework
|
|
for dynamically stepping processor speed, controlling fans, shutting
|
|
down and/or powering subsystems to conserve power and keep the system
|
|
with thermal limits.
|