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.
This commit is contained in:
dholland
parent
cfa69dcf1b
commit
298a4bfa9a
|
|
@ -0,0 +1,336 @@
|
|||
$NetBSD: desktop,v 1.1 2017/01/13 10:17:18 dholland Exp $
|
||||
|
||||
NetBSD Desktop Roadmap
|
||||
======================
|
||||
|
||||
This roadmap deals with desktop support. Note that "desktop support"
|
||||
means several quite different things:
|
||||
- issues pertaining to running the Windows-like Linux desktops
|
||||
(e.g. GNOME, KDE, Mate, Trinity, as well as other similar things
|
||||
like LXDE) on NetBSD in more or less their current form;
|
||||
- issues pertaining to running these systems with NetBSD
|
||||
infrastructure, for better system integration and to avoid
|
||||
depending on unpopular packages like dbus and policykit;
|
||||
- issues specific to developer-oriented desktops;
|
||||
- other issues pertaining to using a NetBSD machine as one's desktop
|
||||
login system, regardless of the UI;
|
||||
- issues pertaining to running or developing a more Unix-oriented
|
||||
desktop environment, which is kind of blue-sky for the time being.
|
||||
|
||||
Also, "desktop support" and "laptop support" are closely related in
|
||||
the sense that in the conventional wisdom laptops run more or less the
|
||||
same user-facing software as desktops. Additional specifically laptop-
|
||||
related issues, such as power management, are discussed in the
|
||||
"mobile" roadmap (q.v.).
|
||||
|
||||
Furthermore, many of the above issues can be ~orthogonally divided
|
||||
into one of the following three broad categories:
|
||||
|
||||
a. Providing new infrastructure for supporting facilities whose
|
||||
needs are reasonably well understood but are not traditionally
|
||||
handled by Unix and/or are not currently handled by NetBSD, or
|
||||
where traditional/existing support is chronically defective.
|
||||
Examples include font management, printing, mounting removable
|
||||
media, and also things like support for location services.
|
||||
|
||||
b. Providing new infrastructure for supporting facilities whose
|
||||
needs are not in fact well understood. This tends to cover the
|
||||
domains where we don't like the GNOME/KDE/Linux tools, like
|
||||
dbus, as well as things that existing desktop environments fall
|
||||
down on entirely, like integrating with large home directory
|
||||
trees.
|
||||
|
||||
c. Refactoring existing infrastructure (whether NetBSD-specific or
|
||||
historical Unix) to integrate new facilities and software models
|
||||
smoothly instead of bolting layers of crud on top of outdated
|
||||
structure. Examples include revisiting the assumption that
|
||||
logins happen on teletypes, and facing the need to restrict the
|
||||
access of large applications rather than giving them all the
|
||||
privileges of the user starting them.
|
||||
|
||||
|
||||
The following elements, projects, and goals are relatively near-term:
|
||||
|
||||
1. Don't ship twm as the default X window manager
|
||||
2. Making removable media work using GNOME/KDE infrastructure
|
||||
3. Making wireless config work using GNOME/KDE infrastructure
|
||||
4. Sane font handling
|
||||
5. Get Eclipse running properly from pkgsrc
|
||||
6. Better printer management
|
||||
7. Work out a long-term plan for compositing, Wayland, and graphics
|
||||
architecture issues
|
||||
|
||||
The following elements, projects, and goals are longer-term:
|
||||
|
||||
8. Publish/subscribe sockets or IPC
|
||||
9. Better native RPC library and tools
|
||||
10. Native removable media handling
|
||||
11. Native wireless config
|
||||
12. User switching and secure attention key
|
||||
13. wscons graphics
|
||||
|
||||
The following elements, projects, and goals are rather blue-sky so far:
|
||||
|
||||
14. Something akin to ARexx
|
||||
15. A more Unix-oriented root window/desktop basis
|
||||
16. Full console virtualization
|
||||
|
||||
|
||||
Explanations
|
||||
============
|
||||
|
||||
|
||||
1. Don't ship twm as the default X window manager
|
||||
|
||||
It's embarrassing that in 2016 we were still shipping twm as the
|
||||
default window system config. Heck, it was embarrassing in 2006. The
|
||||
work needed to move to ctwm has been largely done (by youri) and at
|
||||
least some of it committed, but this still (as of January 2007) isn't
|
||||
enabled by default.
|
||||
|
||||
- As of January 2017 nobody is actively working on this.
|
||||
- It would be silly at this point to release 8.0 without it, so
|
||||
ideally someone will step up to get it finished and enabled.
|
||||
- Contact: XXX please fill in
|
||||
|
||||
|
||||
2. Making removable media work using GNOME/KDE infrastructure
|
||||
|
||||
Ideally when you insert a USB stick it mounts automatically, like with
|
||||
GNOME and KDE on Linux. I believe this is not currently working. It
|
||||
used to depend on hal, which was always problematic and perennially
|
||||
broken, but hal got deprecated and I'm not sure what is even involved.
|
||||
(XXX: someone please clarify.)
|
||||
|
||||
|
||||
3. Making wireless config work using GNOME/KDE infrastructure
|
||||
|
||||
Ideally it would be possible to configure your wireless networking
|
||||
using the GNOME/KDE/etc. tools. I believe this does not work either.
|
||||
(XXX: someone please clarify.)
|
||||
|
||||
|
||||
4. Sane font handling
|
||||
|
||||
See "System-level font handling in Unix" on the wiki projects page.
|
||||
|
||||
- As of January 2017 nobody is actively working on this.
|
||||
- There is currently no clear timeframe or release target.
|
||||
- Contact: dholland
|
||||
|
||||
|
||||
5. Get Eclipse running properly from pkgsrc
|
||||
|
||||
As of last report Eclipse was bodgily packaged (this may not be
|
||||
fixable) and didn't really work (this should be). Because Eclipse is
|
||||
Java this depends on JDK stuff.
|
||||
|
||||
- As of January 2017 nobody is actively working on this.
|
||||
- There is currently no clear timeframe or release target.
|
||||
- Contact: ? (XXX)
|
||||
|
||||
|
||||
6. Better printer management
|
||||
|
||||
See "New LPR/LPD for NetBSD" on the wiki projects page.
|
||||
|
||||
- As of January 2017 nobody is actively working on this.
|
||||
- There is currently no clear timeframe or release target.
|
||||
- Contact: dholland
|
||||
|
||||
|
||||
7. Work out a long-term plan for compositing, Wayland, and graphics
|
||||
architecture issues
|
||||
|
||||
Nobody seems to have a good idea of what the way forward ought to be,
|
||||
so probably it would be advisable for someone to dig into the issues
|
||||
and report back.
|
||||
|
||||
- As of January 2017 nobody is actively working on this.
|
||||
- There is currently no clear timeframe or release target.
|
||||
- Contact: ? (XXX)
|
||||
|
||||
|
||||
8. Publish/subscribe sockets or IPC
|
||||
|
||||
It's clear that even though traditionally Unix has next to no such
|
||||
facilities, a "modern" desktop system requires the ability to post
|
||||
notices about from one component to another. (Probably the closest
|
||||
thing traditional Unix ever had along these lines was comsat(8).)
|
||||
|
||||
dholland observed some time back that there isn't really a problem if
|
||||
what you want to do is contact a well-known service: we have inetd for
|
||||
that, and while inetd could use some polishing before being deployed
|
||||
for such purposes that isn't a very big deal. The interesting case is
|
||||
multicast: when you want to send a notice to anyone who happens to be
|
||||
around and interested in seeing notices of some particular type,
|
||||
without needing to know who they are.
|
||||
|
||||
dbus does this badly, both because the implementation is poor and
|
||||
because the basic concept of a "message bus" is flawed. A better model
|
||||
is publish-subscribe channels: a message sent ("published") on the
|
||||
channel is delivered to all listeners ("subscribers"), and neither the
|
||||
publishers nor the subscribers need to know about one another, only
|
||||
about the existence of the channel... which becomes effectively a well
|
||||
known service.
|
||||
|
||||
The original (very tentative) plan was to wedge publish/subscribe into
|
||||
AF_UNIX sockets, because AF_UNIX sockets already satisfy several
|
||||
important criteria: (1) they have a large and flexible namespace,
|
||||
namely the whole file system namespace; (2) they support credential
|
||||
reporting; (3) the socket/bind/listen/connect API (probably) provides
|
||||
enough flexibility to handle the connection model; and (4) they
|
||||
already exist. However, nobody has yet looked into this very closely
|
||||
and the interface may not turn out to be very suitable after all.
|
||||
|
||||
Note that (like anything of this sort) the naming scheme for the
|
||||
channels is critical, as is the development of sane protocols to run
|
||||
over them. Note that the publish/subscribe sockets should be transport
|
||||
only; protocols should be a higher-level issue. (This is one of a
|
||||
number of things dbus gets wrong.)
|
||||
|
||||
One of the other things this infrastructure should provide is a decent
|
||||
way to post notices (e.g. for media changes, device insertions, and so
|
||||
on) out of the kernel, which has historically always been a problem in
|
||||
Unix.
|
||||
|
||||
This item is sometimes also referred to as "dbus avoidance" -
|
||||
theoretically one could avoid dbus with some other architecture too,
|
||||
but nothing much else has been proposed.
|
||||
|
||||
An example application we already have in base is the notices that
|
||||
sshd sends to blacklistd. Currently this makes a mess if sshd is
|
||||
running and blacklistd isn't.
|
||||
|
||||
- As of January 2017 nobody is actively working on this.
|
||||
- There is currently no timeframe or release target.
|
||||
- Contact: dholland
|
||||
|
||||
|
||||
9. Better native RPC library and tools
|
||||
|
||||
Another thing dbus doesn't do very well: it's an IPC/RPC library. In
|
||||
the long run to support existing desktops we probably need
|
||||
dbus-compatible IPC tools. In the short run though we'd do well to
|
||||
pick or develop something of our own, and (finally) deprecate SunRPC.
|
||||
|
||||
- As of January 2017 nobody is actively working on this.
|
||||
- There is currently no timeframe or release target.
|
||||
- Contact: dholland or ? (XXX)
|
||||
|
||||
|
||||
10. Native removable media handling
|
||||
|
||||
Given publish/subscribe channels, implement proper native support for
|
||||
mounting removable media upon insertion. This should integrate with
|
||||
GNOME/KDE/etc. but also work natively; e.g. provided the right
|
||||
services are running, it should work even when running on a text-only
|
||||
console.
|
||||
|
||||
|
||||
11. Native wireless config
|
||||
|
||||
Similarly, implement a native wireless config scheme. While we
|
||||
currently have wpa_cli, it lacks a certain something...
|
||||
|
||||
|
||||
12. User switching and secure attention key
|
||||
|
||||
See the project page on the wiki.
|
||||
|
||||
- As of January 2017 nobody is actively working on this.
|
||||
- There is currently no timeframe or release target.
|
||||
- Contact: dholland or ? (XXX)
|
||||
|
||||
|
||||
13. wscons graphics
|
||||
|
||||
There's been talk on and off for some time about supporting cairo or
|
||||
qt-embedded or similar things directly on the console. This is
|
||||
probably a good infrastructure step for any UI scheme that doesn't
|
||||
involve an X server, such as potentially phones or tablets. (See the
|
||||
"mobile" roadmap for more on that.)
|
||||
|
||||
|
||||
14. Something akin to ARexx
|
||||
|
||||
We have a number of veteran Amiga users and whenever there's a
|
||||
discussion of dbus usually ARexx eventually comes up. It would be
|
||||
great to have something like ARexx for talking to/scripting/
|
||||
controlling applications. But given that GNOME and KDE and their
|
||||
imitations are all based on Windows and that the state of the art
|
||||
seems to be dbus, if we want this we're going to have to design and
|
||||
build it out ourselves. It would be a good thing to do.
|
||||
|
||||
Just remember that the good parts of ARexx didn't include the Rexx
|
||||
language. :-)
|
||||
|
||||
- As of January 2017 nobody is actively working on this.
|
||||
- There is currently no timeframe or release target.
|
||||
- Contact: mlelstv? (XXX)
|
||||
|
||||
|
||||
15. A more Unix-oriented root window/desktop basis
|
||||
|
||||
All the existing desktops (apart from OS X, which is NextStep, but not
|
||||
all that much different either) are based on Windows. They share a
|
||||
number of properties that are not consistent with the Unix philosophy
|
||||
or design model.
|
||||
|
||||
First, Unix is about files, and like or or not, files in Unix are
|
||||
organized in a hierarchical namespace. The Windows-like desktops, like
|
||||
Windows, provide a file manager as an afterthought and the desktop
|
||||
workspace itself has no notion of current directory, no notion of
|
||||
directory navigation, and only limited notions of interacting with
|
||||
files at all. In fact, the things that show up on the desktop
|
||||
typically live in a reserved directory that the desktop software
|
||||
insists on polluting your homedir with. A Unix desktop should have
|
||||
directory navigation integrated with the root window somehow -- there
|
||||
are many possible ways to do this, and virtually any choice would be
|
||||
better than what you get from GNOME and KDE. It shouldn't be necessary
|
||||
to open a shell (or a "file manager") to work effectively with a large
|
||||
source tree.
|
||||
|
||||
Second, Unix is also about text, and existing desktop software is not.
|
||||
While people tend to think of GUIs and text as mutually exclusive,
|
||||
this is not actually the case: a GUI provides a lot of ways to place
|
||||
and format text that can't be done in text mode (let alone on a
|
||||
teletype) -- a good start, for example, might be to display the first
|
||||
few lines of a file when you roll the mouse over it, but one can go a
|
||||
lot further than that.
|
||||
|
||||
Third, Unix is supposed to be about pluggable components. A Unix
|
||||
desktop should have functionality for plugging components together
|
||||
graphically, whether those components are traditional shell tools or
|
||||
"services" or "objects" or more complex things. No existing desktop
|
||||
has anything like this, certainly not as native functionality.
|
||||
|
||||
Anything like this is going to have to be designed and written, since
|
||||
it's clearly not going to be forthcoming from the Linux desktop folks.
|
||||
(Note that while it would be a big effort it would also be a great
|
||||
publicity lever...)
|
||||
|
||||
|
||||
16. Full console virtualization
|
||||
|
||||
The Unix notion of a login session is stuck in the 70s, where you log
|
||||
in on a glass teletype and that's all you get. The consoles of modern
|
||||
computers have assorted other widgets as well: pointing devices, game
|
||||
controllers, cameras, scanners, removable storage, hotkeys, audio
|
||||
playback and record... not to mention graphics and video. Right now we
|
||||
have a bodgy scheme for chowning or chmod'ing devices on console
|
||||
login; in addition to potentially causing problems (what happens if
|
||||
one user leaves a process behind that's recording audio, then logs out
|
||||
and walks away?) this doesn't work well with multiple users logged in
|
||||
at once on the console. It also doesn't work at all with remote logins.
|
||||
|
||||
In an ideal world, all your console hardware would be tied to your
|
||||
console login session, and virtualized appropriately so that multiple
|
||||
console logins each get suitably arbitrated access. Furthermore, it
|
||||
should be possible to forward your console hardware to a remote login
|
||||
session -- for example if you have a usb stick you should be able to
|
||||
log in somewhere and mount it there.
|
||||
|
||||
Getting to this requires refactoring the way we think about logins and
|
||||
login devices, but it's high time.
|
||||
|
||||
|
|
@ -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)
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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 be in future releases:
|
|||
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 tasks other than the above targets down.
|
|||
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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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)
|
||||
|
||||
|
|
@ -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 devices. Note that there appears to
|
|||
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 import the code from FreeBSD. The
|
|||
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 entails is updating the ZFS
|
|||
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 importance of full-disk
|
|||
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 (the maximum size of a single
|
|||
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 larger than 2 TB) and also for
|
|||
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 the works.
|
|||
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 to implement this.
|
|||
|
||||
[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 lot of prior art that's also
|
|||
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. The nature and structure of
|
|||
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 diverged in different
|
|||
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 profiles touted for nvram
|
|||
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 understand this and be able
|
|||
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 fill this in.] Also the code
|
|||
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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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 implementation, and so a
|
|||
different approach using wrapper functions on tmpfs is being aimed at
|
||||
for 6.0.
|
||||
|
||||
XXX: what's the current state?
|
||||
|
||||
Responsible: rmind
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
Loading…
Reference in New Issue