Module Name: src
Committed By: dholland
Date: Fri Jan 13 10:14:59 UTC 2017
Modified Files:
src/doc/roadmaps: networking storage system
Added Files:
src/doc/roadmaps: mess mobile ports security verification
Log Message:
Update roadmaps, unilaterally, because most of these hadn't been touched
since the pre-6.0 period and nobody else has been doing the work. There's
a lot of things whose current state I don't know; please fill in. Also the
stuff I've added is necessarily biased towards projects I think about, so
please add more.
To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/doc/roadmaps/mess src/doc/roadmaps/mobile \
src/doc/roadmaps/ports src/doc/roadmaps/security \
src/doc/roadmaps/verification
cvs rdiff -u -r1.12 -r1.13 src/doc/roadmaps/networking \
src/doc/roadmaps/system
cvs rdiff -u -r1.20 -r1.21 src/doc/roadmaps/storage
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/doc/roadmaps/networking
diff -u src/doc/roadmaps/networking:1.12 src/doc/roadmaps/networking:1.13
--- src/doc/roadmaps/networking:1.12 Tue Dec 13 09:51:34 2016
+++ src/doc/roadmaps/networking Fri Jan 13 10:14:58 2017
@@ -1,4 +1,4 @@
-$NetBSD: networking,v 1.12 2016/12/13 09:51:34 rjs Exp $
+$NetBSD: networking,v 1.13 2017/01/13 10:14:58 dholland Exp $
NetBSD Networking Roadmap
=========================
@@ -19,6 +19,7 @@ The following features are expected to b
7. netboot from http
8. MP network stack (Layer 3 and below)
9. MP network stack (rest)
+10. Infiniband
We'll continue to update this roadmap as features and dates get firmed up.
@@ -116,6 +117,13 @@ Make multi-threaded network stack. Get t
Responsible: TBD
Status: not started
+10. Infiniband
+--------------
+
+We do not really have Infiniband support. We should; since it still
+hasn't quite died, it probably isn't going to.
+
+
Matt Thomas
Alistair Crooks
Sat Jan 14 11:44:46 PST 2012
@@ -123,3 +131,5 @@ Christos Zoulas
Tue May 17 16:46:54 EDT 2016
Ryota Ozaki
Wed May 18 18:07:43 JST 2016
+dholland
+Fri Jan 13 00:53:46 EST 2017
Index: src/doc/roadmaps/system
diff -u src/doc/roadmaps/system:1.12 src/doc/roadmaps/system:1.13
--- src/doc/roadmaps/system:1.12 Fri Jan 13 05:45:46 2017
+++ src/doc/roadmaps/system Fri Jan 13 10:14:58 2017
@@ -1,21 +1,29 @@
-$NetBSD: system,v 1.12 2017/01/13 05:45:46 dholland Exp $
+$NetBSD: system,v 1.13 2017/01/13 10:14:58 dholland Exp $
NetBSD System Roadmap
=====================
-This is a small roadmap document, and deals with the main system
-aspects of the operating system.
+This is a roadmap document dealing deals with core system aspects of
+the operating system.
-The following elements, projects, and goals will appear in NetBSD 8.0:
+The following elements, projects, and goals are considered strategic
+priorities for the project:
-The following projects may make it into future releases:
-3. Full kernel preemption for real-time threads
+1. Tickless timing and scheduling (discussed in the mobile roadmap)
+2. Long-term graphics architecture (discussed in the desktop roadmap)
+8. Processor and cache topology aware scheduler
+
+The following elements, projects, and goals are not strategic
+priorities but are still important undertakings worth doing:
+
+3. Full kernel preemption for real-time threads on non-x86
4. POSIX shared memory
6. Better resource controls
7. Improved observability: online crashdumps, remote debugging
-8. Processor and cache topology aware scheduler
-We'll continue to update this roadmap as features and dates get firmed up.
+The following elements, projects, and goals are perhaps less pressing;
+this doesn't mean one shouldn't work on them but the expected payoff
+is perhaps less than for other things:
Some explanations
@@ -45,6 +53,8 @@ there were some concerns with the kernel
different approach using wrapper functions on tmpfs is being aimed at
for 6.0.
+XXX: what's the current state?
+
Responsible: rmind
Index: src/doc/roadmaps/storage
diff -u src/doc/roadmaps/storage:1.20 src/doc/roadmaps/storage:1.21
--- src/doc/roadmaps/storage:1.20 Thu Nov 10 21:28:15 2016
+++ src/doc/roadmaps/storage Fri Jan 13 10:14:58 2017
@@ -1,4 +1,4 @@
-$NetBSD: storage,v 1.20 2016/11/10 21:28:15 jdolecek Exp $
+$NetBSD: storage,v 1.21 2017/01/13 10:14:58 dholland Exp $
NetBSD Storage Roadmap
======================
@@ -52,7 +52,7 @@ is where it's at for remote block device
be no compelling reason to move the target to the kernel or otherwise
make major architectural changes.
- - As of November 2015 nobody is known to be working on this.
+ - As of January 2017 nobody is known to be working on this.
- There is currently no clear timeframe or release target.
- Contact agc for further information.
@@ -71,8 +71,9 @@ only step that has been taken is to impo
next step is to update that import (since it was done a while ago now)
and then work on getting it to configure and compile.
- - As of November 2015 nobody is working on this, and a volunteer to
- take charge is urgently needed.
+ - As of January 2017 pgoyette has done a bit of prodding of the code
+ recently, but otherwise nobody is working on this, and a volunteer to
+ take charge and move it forward rapidly is urgently needed.
- There is no clear timeframe or release target, although having an
experimental version ready for -8 would be great.
- Contact dholland for further information.
@@ -145,7 +146,7 @@ really working. One of the things this e
code, as what we have is rather old. The Illumos version is probably
what we want for this.
- - There has been intermittent work on zfs, but as of November 2015
+ - There has been intermittent work on zfs, but as of January 2017
nobody is known to be actively working on it
- There is no clear timeframe or release target.
- Contact riastradh or ?? for further information.
@@ -184,7 +185,7 @@ Given the increasing regulatory-level im
encryption, this is at least a de facto requirement for using NetBSD
on laptops in many circumstances.
- - As of November 2015 nobody is known to be working on this.
+ - As of January 2017 nobody is known to be working on this.
- There is no clear timeframe or release target.
- Contact dholland for further information.
@@ -196,12 +197,12 @@ The tls-maxphys branch changes MAXPHYS (
I/O request) from a global fixed constant to a value that's probed
separately for each particular I/O channel based on its
capabilities. Large values are highly desirable for e.g. feeding large
-disk arrays but do not work with all hardware.
+disk arrays and SSDs, but do not work with all hardware.
The code is nearly done and just needs more testing and support in
more drivers.
- - As of November 2015 nobody is known to be working on this.
+ - As of January 2017 nobody is known to be working on this.
- There is no clear timeframe or release target.
- Contact tls for further information.
@@ -244,9 +245,10 @@ for use on shingled disks (which are lar
use on disk arrays (ditto) this is something of a problem. A 64-bit
version of LFS for large volumes is in the works.
- - As of November 2015 dholland is working on this.
- - It is close to being ready for at least experimental use and is
- expected to be in 8.0.
+ - dholland was working on this in fall 2015 but time to finish it
+ dried up.
+ - The goal now is to get a few remaining things done in time for 8.0
+ so it will at least be ready for experimental use there.
- Responsible: dholland
@@ -256,11 +258,13 @@ version of LFS for large volumes is in t
Support for per-process variation of the file system namespace enables
a number of things; more flexible chroots, for example, and also
potentially more efficient pkgsrc builds. dholland thought up a
-somewhat hackish but low-footprint way to implement this.
+somewhat hackish but low-footprint way to implement this, and has a
+preliminary implementation, but concluded the scheme was too fragile
+for production. A different approach is probably needed, although the
+existing code could be tidied up and committed if that seems desirable.
- - As of November 2015 dholland is working on this.
- - It is scheduled to be in 8.0.
- - Responsible: dholland
+ - As of January 2017 nobody is working on this.
+ - Contact: dholland
10. lvm tidyup
@@ -268,7 +272,7 @@ somewhat hackish but low-footprint way t
[agc says someone should look at our lvm stuff; XXX fill this in]
- - As of November 2015 nobody is known to be working on this.
+ - As of January 2017 nobody is known to be working on this.
- There is no clear timeframe or release target.
- Contact agc for further information.
@@ -289,7 +293,7 @@ plan; it is a complicated area with a lo
reportedly full of patent mines. There are a couple of open FTL
implementations that we might be able to import.
- - As of November 2015 nobody is known to be working on this.
+ - As of January 2017 nobody is known to be working on this.
- There is no clear timeframe or release target.
- Contact dholland for further information.
@@ -304,7 +308,7 @@ flash translation layers found in SSDs.
shingle translation layers is still being researched; however, at some
point we will want to support these things in NetBSD.
- - As of November 2015 one of dholland's coworkers is looking at this.
+ - As of 2016 one of dholland's coworkers was looking at this.
- There is no clear timeframe or release target.
- Contact dholland for further information.
@@ -347,7 +351,7 @@ the Dragonfly and NetBSD VFS layers have
directions from the original 4.4BSD, may not be entirely trivial
either.
- - As of November 2015 nobody is known to be working on this.
+ - As of January 2017 nobody is known to be working on this.
- There is no clear timeframe or release target.
- There probably isn't any particular person to contact; for VFS
concerns contact dholland or hannken.
@@ -393,7 +397,7 @@ this issue; given the performance profil
technologies, a plain RAM disk like md(4) is sufficient both
structurally and for performance analysis.
- - As of November 2015 nobody is known to be working on this. Some
+ - As of January 2017 nobody is known to be working on this. Some
time back, uebayasi wrote some preliminary patches, but they were
rejected by the UVM maintainers.
- There is no clear timeframe or release target.
@@ -410,6 +414,7 @@ The various tools must be modified to un
to copy them if requested. Also tools to manipulate the data will
need to be written.
+
18. coda maintenance
--------------------
@@ -418,13 +423,15 @@ upstream, or something of the sort; XXX
appears to have an ugly incestuous relationship with FFS. This should
really be cleaned up. That or maybe it's time to remove Coda.
- - As of November 2015 nobody is known to be working on this.
+ - As of January 2017 nobody is known to be working on this.
- There is no clear timeframe or release target.
- There isn't anyone in particular to contact.
- Circa 2012 christos made it work read-write and split it
into modules. Since then christos has not tested it.
+
Alistair Crooks, David Holland
Fri Nov 20 02:17:53 EST 2015
Sun May 1 16:50:42 EDT 2016 (some updates)
+Fri Jan 13 00:40:50 EST 2017 (some more updates)
Added files:
Index: src/doc/roadmaps/mess
diff -u /dev/null src/doc/roadmaps/mess:1.1
--- /dev/null Fri Jan 13 10:14:59 2017
+++ src/doc/roadmaps/mess Fri Jan 13 10:14:58 2017
@@ -0,0 +1,219 @@
+$NetBSD: mess,v 1.1 2017/01/13 10:14:58 dholland Exp $
+
+NetBSD Messes and Tentacular Horrors Roadmap
+============================================
+
+There are a number of places in NetBSD where the code is substandard,
+or messy, or badly structured, or just excessively complicated. These
+are liabilities. Fixing them is a goal, not just because they
+themselves cause problems but because every pile of glop in the system
+functions as an implicit excuse to not clean up others.
+
+There are two kinds of these messes: with some, the consequences are
+relatively localized, and while dealing with that particular area of
+the code may be nasty the issues are otherwise mostly not visible.
+With others, the horror spreads and contaminates everything that comes
+near it. The latter are particularly important to clean out.
+
+The things listed here are listed here because they have been cited as
+problems; some of these are regularly cited as problems. The goal of
+this file is not to criticize the code or point fingers (some of these
+messes come down to us all the way from 4.3 and are the result of
+always patching and never fixing; but some of them have been
+self-inflicted because they seemed like a good idea at the time, or
+they were what we had, or whatever) but to document areas that could
+use a good rototill or two.
+
+These are listed in a perceived order of priority based on how bad the
+mess is, how toxic it is to things around it, how much it's
+interfering with other development, and how unreliable the affected
+code is as a result.
+
+ 1. namei, ufs_lookup, vfs_rename
+ 2. buffercache
+ 3. network interfaces
+ 4. mbufs
+ 5. tty code
+ 6. nsswitch code in libc
+ 7. proplib
+ 8. kauth
+ 9. sysmon_envsys
+ 10. atf
+ 11. pam
+
+
+Explanations
+============
+
+
+1. namei, ufs_lookup, vfs_rename
+
+namei is central to everything and it's been horrible since at least
+4.3 and maybe longer. A fair amount of work has been put into it, and
+a number of the particular horrors have been eliminated, but there's
+still quite a bit left to do.
+
+The immediate next step is to introduce VOP_PARSEPATH (a new VOP call
+to allow the two filesystems we have that consume more than one
+directory component at a time to do so in a more tractable way) and
+then it's time to start implementing namei_parent, a version that
+stops at the parent with one component name left to go. This will
+allow a much saner interface to directory ops, including rename, and
+once those are done a lot of the complexity currently in namei and in
+the VOP_LOOKUP interface can be removed.
+
+ - dholland is working on this intermittently.
+ - VOP_PARSEPATH is ready to commit and is expected to make 8.0.
+ There is currently no clear timeframe for anything beyond that.
+ - Responsible: dholland
+
+
+2. buffercache
+
+The buffercache code is messy and full of flag words that filesystems
+muck with freely and not necessarily with correct locking. It is
+suspected that there is a lot of incorrect locking. Also, a lot of the
+naming and terminology (things like BO_DELWRI) is really ancient and
+reflects non-current assumptions about the way file system buffers
+should work.
+
+ - As of January 2017 nobody is currently working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact dholland for further information.
+
+
+3. network interfaces
+
+The network interface structure and its associated support code has no
+abstraction, no encapsulation, and no safety. It badly needs
+rationalization.
+
+ - As of January 2017 nobody is currently working on this directly,
+ though some aspects fall under the multiprocessor network stack
+ project.
+ - There is currently no clear timeframe or release target.
+ - Contact rmind for further information.
+
+
+4. mbufs
+
+The mbuf code has some concept of an interface, but lots of the code
+manipulating mbufs doesn't use that interface, and there's still no
+encapsulation and no safety.
+
+ - As of January 2017 nobody is currently working on this directly,
+ though some aspects fall under the multiprocessor network stack
+ project.
+ - There is currently no clear timeframe or release target.
+ - Contact rmind or dholland for further information.
+
+
+5. tty code
+
+The tty subsystem has no concept of an interface at all, and there are
+large wodges of code cutpasted all over everywhere in gazillions of
+tty client drivers. There's no encapsulation either and absolutely no
+safety. Furthermore the locking model is bodgy.
+
+In addition to this the division of responsibility between "tty" and
+"serial port" is wrong. There are a number of drivers (e.g. for mice)
+that are partially ttys because they're things that are more or less
+serial ports, but they were never meant to be used for logins and
+can't be. These should be disentangled from the tty layer.
+
+Finally, the notion of line disciplines is a legacy mess that ought to
+get turned into a system of device attachments - a line discipline is
+a driver attached on top of the line, except that the concept appeared
+long before anyone really thought up device attachments as we know
+them now.
+
+ - As of January 2017 nobody is currently working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact dholland for further information.
+
+
+6. nsswitch code in libc
+
+The nsswitch code in libc is not all that bad in the sense of being
+horrible code you lose sanity points to look at, but it's structured
+all wrong. It can't be cleaned up without doing a libc bump, which is
+a big deal, but if we do ever manage to get that libc bump done it's
+important that the nsswitch code get revised then.
+
+ - As of January 2017 nobody is currently working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact dholland or joerg for further information.
+
+
+7. proplib
+
+Removal of proplib is and has been a goal of several developers for
+some time, but there's not been any consensus on a replacement. Much
+has been written on this elsewhere so I'm not going to repeat it all
+here.
+
+ - As of January 2017 nobody is currently working on this, but several
+ partly-finished proplib replacement candidates exist.
+ - There is currently no clear timeframe or release target.
+ - Contact dholland, rmind, riastradh, or any of a number of other
+ people for further information.
+
+
+8. kauth
+
+kauth is far too complicated for security code and its API is full of
+void pointers and horribly unsafe. There is no consensus on what to do
+about it, though. Part of the problem is that kauth itself is at least
+three different things that need to be disentangled: (a) an API for
+random kernel code to issue security checks; (b) an implementation of
+security check logic; and (c) an extensibility framework for that
+security check logic.
+
+ - As of January 2017 nobody is currently working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact dholland for further information.
+
+
+9. sysmon_envsys
+
+sysmon_envsys is also too complicated. XXX: someone fill in more here
+please.
+
+ - As of January 2017 nobody is currently working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact: ? (XXX)
+
+
+10. atf
+
+atf is horribly complicated and very expensive (apparently it takes
+all day to compile just atf on an sgimips) and doesn't provide a whole
+lot of bang for the buck. It is also frequently cited as an impediment
+to getting new tests written and deployed. It is not at all clear what
+to do about it.
+
+ - As of January 2017 nobody is currently working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact: ? (XXX)
+
+
+11. pam
+
+pam, though a more or less standard API/interface, has a range of
+problems, one being that after the manner of sysvinit it works by
+exposing a mechanism and you configure it by mucking with the
+mechanism until it produces the behavior you want. (Except that if you
+muck with its mechanism, you end up locking yourself out.) In practice
+editing pam configs seems to be limited to specialists, and that's
+really not suitable for security software.
+
+It is very unclear what to do about it though. It's a standard API and
+there are a number of 3rd-party pam modules, some of which people need
+to be able to use. Once upon a time there was a similar thing called
+bsdauth, but it never really seems to have been a credible alternative.
+Probably the right thing to do is to completely redesign
+how logging in works, but that's a Big Deal.
+
+ - As of January 2017 nobody is currently working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact: ? (XXX)
Index: src/doc/roadmaps/mobile
diff -u /dev/null src/doc/roadmaps/mobile:1.1
--- /dev/null Fri Jan 13 10:14:59 2017
+++ src/doc/roadmaps/mobile Fri Jan 13 10:14:58 2017
@@ -0,0 +1,130 @@
+$NetBSD: mobile,v 1.1 2017/01/13 10:14:58 dholland Exp $
+
+NetBSD Mobile Roadmap
+=====================
+
+This roadmap is meant to cover issues specifically pertaining to
+mobile use, that is, devices that run on batteries and get carried
+around. This includes:
+ - phones
+ - tablets
+ - tablet PCs
+ - laptops
+The typical assumption right now is that phones and tablets have one
+software stack (iOS, Android) and work one way, and laptops, including
+tablet PCs, have another software stack (Windows, MacOS, Linux) and
+work another way. The "laptop" software stack is more or less the same
+as the "desktop" software stack, modulo some laptop-specific issues.
+Those laptop-specific issues are covered in this file; the rest of
+that software stack is discussed in the "desktop" roadmap. This file
+also covers the phone/tablet software stack.
+
+The following elements, projects, and goals are considered strategic
+priorities for the project:
+
+ 1. Tickless timers/scheduling
+
+These elements, projects, and goals are more or less long-term goals:
+
+ 2. Power management concerns
+ 3. Suspending
+ 4. atrun considered harmful
+ 5. (Wireless config issues are in the "desktop" roadmap)
+
+These elements, projects, and goals are for the time being pretty much
+blue sky:
+
+ 6. Touchscreen (phone/tablet) UI
+ 7. Support for phone hardware
+
+
+Explanations
+============
+
+1. Tickless timers/scheduling
+
+The basic premise with a tickless system is that instead of generating
+a timer interrupt HZ times a second, one programs a high-resolution
+timer on the fly to interrupt the next time something needs to happen.
+This can substantially reduce the number of timer interrupts taken,
+and also importantly it avoids waking the system up regularly when
+otherwise idle and reduces power consumption and heating.
+
+There has been a fair amount of talk about this but so far no real
+action.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact: ? (XXX)
+
+
+2. Power management concerns
+
+NetBSD's power management infrastructure is fairly lacking. We don't
+have good CPU clock rate throttling, we mostly don't have the ability
+to power down idle devices, and we don't have a configuration and
+control setup to manage it either. On x86 we also don't support a
+number of important ACPI sleep/idle states.
+
+At the moment there isn't even a good inventory of what needs to be
+done in this department. Someone please write it and put it here.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact: ? (XXX)
+
+
+3. Suspending
+
+Currently suspending mostly doesn't work, and the chances of being
+able to suspend any given laptop model successfully are low until
+someone using it gets annoyed enough to sit down and make it behave.
+
+We need to fix this, both by adding suspend hooks to drivers that are
+missing them and also (ideally) by coming up with a better way to cope
+with drivers that don't know how to suspend.
+
+ - As of January 2017 nobody is known to be specifically working on
+ this, although work on individual drivers occurs sporadically.
+ - There is currently no clear timeframe or release target.
+ - Contact: ? (XXX)
+
+
+4. atrun considered harmful
+
+There are a number of things on the system that unnecessarily wake up
+and take cpu time and power on a regular basis. One of the big
+offenders is atrun -- it should be changed either to be a daemon that
+wakes up only when it has a job to run, integrated into cron to the
+same end, or changed around in some other similar fashion.
+
+One can always turn atrun off, but there's no particular reason that
+at(1) functionality should be unavailable on laptops.
+
+ - As of January 2017 nobody is known to be specifically working on
+ this, although work on individual drivers occurs sporadically.
+ - There is currently no clear timeframe or release target.
+ - Contact: ? (XXX)
+
+
+6. Touchscreen (phone/tablet) UI
+
+We'd rather like to be able to run on phones, and that means having a
+UI suitable for a phone -- a shell isn't going to cut it, and even a
+shell coupled with a keyboard app isn't really the ticket.
+
+This has many of the same kinds of issues as desktop software. Some of
+the specific issues are different; e.g. location handling is a lot
+more critical for phones than for desktops and even laptops.
+
+While we don't currently run on any phone platforms (see below)
+there's nothing stopping working on this using older PDA/palmtop
+hardware like hpcarm.
+
+
+7. Support for phone hardware
+
+We don't currently support any phone hardware platforms at all. It
+would be good to. Among other things this requires finishing arm64
+support, but there's also lot of drivers to write.
+
Index: src/doc/roadmaps/ports
diff -u /dev/null src/doc/roadmaps/ports:1.1
--- /dev/null Fri Jan 13 10:14:59 2017
+++ src/doc/roadmaps/ports Fri Jan 13 10:14:58 2017
@@ -0,0 +1,106 @@
+$NetBSD: ports,v 1.1 2017/01/13 10:14:58 dholland Exp $
+
+NetBSD Ports Roadmap
+====================
+
+This roadmap covers ports and port-specific issues, and also bus-level
+material even if it's not strictly port-specific.
+
+The following elements, projects, and goals are considered strategic
+priorities for the project:
+
+ 1. EFI boot for x86
+ 2. xhci support
+ 3. Get arm64/aarch64 working
+
+The following elements, projects, and goals are not strategic
+priorities but are still important undertakings worth doing:
+
+ 4. USER_LDT for amd64
+ 5. riscv and/or or1k ports
+ 6. cheri port
+
+The following elements, projects, and goals are perhaps less pressing;
+this doesn't mean one shouldn't work on them but the expected payoff
+is perhaps less than for other things:
+
+ 7. pdp10/risc36/odd-bitsize ports
+
+
+Explanations
+============
+
+
+ 1. EFI boot for x86
+
+EFI boot is now often required for new x86 hardware. This is
+effectively a mandatory item for -8. Fortunately, nonaka has most of
+it done, though it's not yet committed.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact agc for further information.
+
+
+ 2. xhci support
+
+xhci is also critical for new x86 hardware. Enough has been committed
+to be able to use USB on xhci machines; but (AIUI) the USB 3.0
+specific features mostly aren't implemented yet. We would like to get
+this pulled into -7
+
+ - As of January 2017 ... who is working on this? XXX
+ - Contact jakllsch (?) for further information.
+
+
+ 3. Get arm64/aarch64 working
+
+We have some arm64 code but apparently it doesn't really work yet.
+
+ - As of January 2017 nobody is known to be actively working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact: ? (XXX)
+
+
+ 4. USER_LDT for amd64
+
+The amd64 port is lacking the USER_LDT bits needed to be able to run
+Wine. Adding these bits does not seem to be a particularly large job
+(and some of the bits are in place already) but it persistently
+doesn't get done. Money's been offered in the past, without result.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact ? (XXX) for further information.
+
+
+ 5. riscv and/or or1k ports
+
+We have some riscv code and a bit of or1k code, but neither is done.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact matt@ for further information.
+
+
+ 6. cheri port
+
+https://cheri-cpu.org
+There are a number of reasons to tackle this; it will serve as a code
+quality lever. Also there's already a FreeBSD port to steal from.
+
+
+ 7. pdp10/risc36/odd-bitsize ports
+
+There's been a fair amount of loose talk over the years about doing a
+port to a machine that's got 9-bit bytes, or is word-addressed, or
+both. The PDP-10 is one such target; it's also been observed that a
+more modern architecture would probably be more likely to allow a
+vaguely performant FPGA implementation, and something tentatively
+called "risc36" was conceived.
+
+This is both a quixotic retrocomputing project and also a quixotic
+code quality project: making the NetBSD code base work on either
+word-addressed machines or 9-bit/36-bit machines or both would be good
+for it. However, it's also a rather large undertaking.
+
Index: src/doc/roadmaps/security
diff -u /dev/null src/doc/roadmaps/security:1.1
--- /dev/null Fri Jan 13 10:14:59 2017
+++ src/doc/roadmaps/security Fri Jan 13 10:14:58 2017
@@ -0,0 +1,82 @@
+$NetBSD: security,v 1.1 2017/01/13 10:14:58 dholland Exp $
+
+NetBSD Security Roadmap
+=======================
+
+This roadmap discusses security-related features.
+
+The following elements, projects, and goals are considered strategic
+priorities for the project:
+
+ 1. PaX aslr, mprotect, and segvguard are on by default now; this will
+ be in 8.0.
+ 2. Transparent full-disk encryption (discussed in the storage roadmap)
+ 3. User-switching and secure attention key (see desktop roadmap)
+
+The following elements, projects, and goals are not strategic
+priorities but are still important undertakings worth doing:
+
+ 4. Security restriction framework for large/less trusted applications
+ 5. Interface for location, accelerometer, and similar sensitive services
+
+
+Explanations
+============
+
+
+4. Security restriction framework for large/less trusted applications
+
+Traditionally in Unix permissions go with the user logged in, and all
+programs that are run execute with the credentials and permissions of
+that user. (Except for setugid programs, which execute with additional
+permissions.)
+
+This makes sense for programs like cat(1) or grep(1) that work with
+user data in the traditional shell environment. However, it is
+unsatisfactory for large semi-trusted applications such as web
+browsers, and entirely unsuitable for 3rd-party "apps" such as found
+on phones, which routinely contain spyware.
+
+We would like to have a permissions framework that works on a
+per-application basis and allows imposing restrictions on what apps
+may do, what data apps may read, and also supports policies like
+"cannot talk on the network after reading user data".
+
+Such a framework is entirely different from traditional Unix
+permissions and requires careful thought and design. Prior art is
+mostly not very good; e.g. Android's app permissions framework is both
+not expressive enough to pose serious barriers to spyware, and too
+complicated for typical users to cope with effectively. Meanwhile,
+system-call-based restrictions like seccomp/seccomp-bpf in Linux are
+messy and complicated and hard to use effectively. OpenBSD's "pledge"
+has been widely criticized for a range of reasons. Most of these
+models also do not provide for lying to apps that demand access you
+don't want to give them.
+
+dholland was working on this with some undergrads a while back and
+there's a design that may be of some value, although the prototype
+implementation was not a success.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact dholland for further information.
+
+
+5. Interface for location, accelerometer, and similar sensitive services
+
+Currently in NetBSD we have no infrastructure for the "new" hardware
+interfaces typically found in phones, like GPS location information,
+accelerometer and orientation data, and so forth.
+
+There is probably no need to invent new APIs for retrieving this data,
+but we do need a sound underlying framework with security controls in
+place, as many of these data sources provide information that is
+either sensitive or can be used to derive sensitive information.
+
+(Note also that it's been shown that location data can be derived from
+monitoring battery level so that one's also sensitive.)
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact: ? (XXX)
+
Index: src/doc/roadmaps/verification
diff -u /dev/null src/doc/roadmaps/verification:1.1
--- /dev/null Fri Jan 13 10:14:59 2017
+++ src/doc/roadmaps/verification Fri Jan 13 10:14:58 2017
@@ -0,0 +1,101 @@
+$NetBSD: verification,v 1.1 2017/01/13 10:14:58 dholland Exp $
+
+NetBSD Verification Roadmap
+===========================
+
+This roadmap covers things that we intend or would like to do pursuant
+to verification and quality control.
+
+The following elements, projects, and goals are relatively near-term:
+
+ 1. Cut down the Coverity backlog
+ 2. Deploy asan/ubsan
+ 3. Deploy clang-static-analyzer
+
+The following elements, projects, and goals are longer-term:
+
+ 4. mint
+ 5. Database-driven program analyzer
+
+The following elements, projects, and goals are rather blue-sky so far:
+
+ 6. Use Frama-C to verify fsck_ffs
+
+
+Explanations
+============
+
+1. Cut down the Coverity backlog
+
+Coverity provides us with free analysis reports, which we sometimes
+handle and sometimes don't. Apparently though Linux has a lower number
+of Coverity hits per line than we do; that seems fundamentally wrong
+and something that should get attention. Most of the problems Coverity
+finds are pretty easily fixed, or are false positives.
+
+ - As of January 2017 coypu has been working on this. Christos often
+ also fixes these.
+ - There is currently no clear timeframe or release target.
+ - Contact christos for further information.
+
+
+2. Deploy asan/ubsan
+
+It ought to be possible to build any program in NetBSD, or the whole
+world, using asan and/or ubsan. Currently there isn't an easy way to
+do this. We should also do regular test runs with asan and ubsan
+engaged.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact joerg (?) for further information.
+
+
+3. Deploy clang-static-analyzer
+
+There is some makefile support for running clang-static-analyzer, but
+it doesn't get done regularly. This should probably get added to the
+autobuilds.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact joerg for further information.
+
+
+4. mint
+
+A while back dholland started on a replacement for the existing lint,
+since lint is not really smart enough to be useful and its code is
+only marginally maintainable. The code is in othersrc, but it needs
+some tidying before anyone else tries hacking on it.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Responsible: dholland
+
+
+5. Database-driven program analyzer
+
+In the long run we would like to have a program analyzer that can
+scale to the whole kernel and can do differential analyses across
+different versions. This is a nontrivial project though.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact: dholland
+
+
+6. Use Frama-C to verify fsck_ffs
+
+Frama-C is a framework for doing formal verification of C code using
+(mostly) precondition/postcondition specs. It is not everything one
+necessarily wants in a verification framework; but on the other hand
+it exists and people do use it.
+
+fsck_ffs seems like a good candidate for this because it's
+mission-critical and what it needs to do is comparatively well
+understood even in detail. However, the code may be too messy.
+
+ - As of January 2017 nobody is known to be working on this.
+ - There is currently no clear timeframe or release target.
+ - Contact: dholland
