Return to ROADMAP CVS log

Up to [cvs.NetBSD.org] / src / doc

Per agc, note that the ROADMAP file is on its way out.

#	$NetBSD: ROADMAP,v 1.24 2008/08/06 19:52:43 perry Exp $

*** THIS FILE IS OBSOLETE ***

Although many of the projects in this file are still current and
valid, roadmap information is now stored in the src/doc/roadmaps
directory.

This file is temporarily retained to allow the information in it to be
transitioned.

------------------------------------------------------------


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.

PLEASE NOTE THAT THIS IS A VOLUNTEER PROJECT, AND THAT NONE OF THESE 
RELEASE VERSIONS, OR NAMES, IS A GUARANTEE OF THE FUNCTIONALITY BEING  
COMPLETE OR EVEN STARTED.  INTERESTED PARTIES SHOULD CONTACT

        core@NetBSD.org

FOR MORE INFORMATION.


1. Platform independent kernel
==============================
aa. Scheduler works
    Separation of context switching and thread scheduling.
	Responsible: yamt
	ETA: 5.0 (yamt-idlelwp branch)
    Generic scheduler API for modular implementations.
	Responsible: dsieger
	ETA: 5.0 (merged in yamt-idlelwp branch)
    New scheduler supporting POSIX Real-time features, CPU affinity and
    having a better support for MP systems.
	Responsible: rmind
	ETA: 5.0

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.
	Responsible: ad
	ETA: 5.0 (vmlocking2 branch)

ac. Expansion of wedge support
    Complete the development of wedges and retire disklabels except
    where needed for compatibility.
	Responsible: thorpej (possibly)
	ETA: 5.0

ad. Volume management
    Allow us to grow, shrink, and move partitions (and, where possible,
    filesystems).
	Responsible: TBD
	ETA: ?

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.
	Responsible: simonb
	ETA: 5.0 (journaling + snapshots don't work together yet though)

af. Expansion of ieee1394 support
    Where possible, fully support DV, disk, and network devices.
	Responsible: TBD
	ETA: Preliminary firewire support is in 4.0

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.
	Responsible: bouyer
	ETA: ?

ah. Suspend and resume support
    We should be able to fully use suspend and resume on PCs, macppc,
    and anyone else who supports it in hardware (sparc, hpcsh, hpcarm, etc).
	Responsible: jmcneill, joerg
	ETA: 5.0

ai. Complete support for LWPs
    There are still vestiges of the kernel that predate LWPification
    and should be updated.  [ What other than ktrace? ]
	Responsible: darrenr, skrll, christos did ktrace-lwp
	ETA: 4.0

aj. PTHREAD_CONCURRENCY > 1 support
    A single process that uses threads should be able to reliably
    use more than one CPU.
	Responsible: ad
	ETA: 5.0  (1:1 pthread come with newlock2)

ak. AIO support
    POSIX aio_*() with full support for Asynchronous I/O (AIO) in the
    kernel.
	Responsible: rmind
	ETA: 5.0

al. Modern parallel port support
    Complete support for bidirectional and "advanced" functionality
    from parallel ports.
	Responsible: jdolecek
	ETA: ?

am. NFSv4
    Bring our NFS up to current standards.
	Responsible: TBD
	ETA: ?

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, from thorpej.  It requires some
    overhaul of cpu_switch/scheduler so that mutex_*(9) and ltsleep(9)
    can interlock.
	Responsible: ad
	ETA: 5.0  (newlock2)

ao. Review TCP/IP developments
    Fix NewReno
	Responsible: mycroft
	ETA: 3.0
    Add SACK support to the kernel.
	Responsible: kurahone
	ETA: 3.0
    Add ECN support to the kernel.
	Responsible: rpaulo
	ETA: 5.0
    Look into other "recent" and current TCP/IP research. Adapt our stack
    to the more modern world.
	Responsible: TBD
	ETA: ?

ap. Kernel linker (ala FreeBSD's kld)
	Responsible: TBD
	ETA: ?

aq. CARP/VRRP
    Functionality is great, but there might be some concern here over
    Cisco patents.
	Responsible: liamfoy
	ETA: 4.0

ar. UDF filesystem support
    OpenBSD has recently added this.
	Responsible: reinoud
	ETA: 4.0

as. RAIDFrame support for 3-way RAID 1
	Responsible: TBD
	ETA: ?

at. RAIDFrame support for RAID 6
	Responsible: oster
	ETA: 5.0?

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.
	Responsible: TBD
	ETA: ?

av. iSCSI initiator support
    We should be able to use iSCSI volumes.
	Responsible: agc
	ETA: 5.0

aw. Run-time changeable limits to SysV IPC
    Some of the limits for SysV IPC are hardcoded in the kernel
    configuration--these should be changable via sysctl.
	Responsible: rmind
	ETA: 4.0

ax. NUMA support
    To achieve this goal, the CPU scheduler should be modified to take into
    account the distances and grouping of CPUs.  Also, support of memory
    blocks should be implemented in the VM subsystem.
	Responsible: TBD
	ETA: ?

2. Platform independent userland
================================
aa. Keep up with the X world
    Track X.org progress.  Maintain existing XFree86.
	Responsible: a cast of thousands
	ETA: ongoing

ab. Reentrant libraries
    Make sure that all libraries are re-entrant and usable for threaded
    applications.
	Responsible: ginsbach and others
	ETA: 5.0?

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.
	Responsible: mrg, matt
	ETA: 4.0

ad. gdb updates
	Responsible: skrll
	ETA: 5.0

ae. binutils updates
    Probably go along with gdb updates.
	Responsible: skrll
	ETA: 4.0

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).
	Responsible: TBD
	ETA: ?

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.
	Responsible: dyoung, skrll, scw and others
	ETA: 4.0

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.
        (a) Support cond. printf fmt. 4.0 will have vfwprintf with
	    positional parameter support; 5.0 will have vfprintf with
	    positional parameter support.
		Responsible: christos
		ETA: 5.0
        (b) Support LC_COLLATE
        (c) mklocale(1) -> localedef(1)
        (d) wchar_t in C++
        (e) i18nize userland commands
        (f) in-kernel iconv
		Responsible: TBD
		ETA: ?

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.
	Responsible: apb
	ETA: 4.0

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, e.g. pkgsrc-wip/pkg_select.
	Responsible: agc and others
	ETA: 4.0

ak. Native signing/privacy software
    This could be BPG (from SoC) or openpgp-sdk.
	Responsible: agc, cjs and others
	ETA: 4.0?

al. Userland version identification
    What binaries are installed?  Who really knows?  This relates at
    least somewhat to (ai).
	Responsible: TBD
	ETA: ?

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.
	Responsible: TBD
	ETA: ?

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.
	Responsible: TBD
	ETA: ?

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.
	Responsible: TBD
	ETA: ?

ad. NDIS
    Support for binary network drivers on x86 platforms.
	Responsible: rittera
	ETA: 4.0

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.
	Responsible: TBD
	ETA: ?

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.
    We also need to migrate all the tests that currently live in
    'regress' to 'tests' so that they can make use of ATF.
    ( Need to virtualize some with qemu or similar? )
	Responsible: jmmv
	ETA: 5.0 should have most of regress converted

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.
	Responsible: the Java porting crew
	ETA: ?

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.
	Responsible: TBD
	ETA: ?