xref: /netbsd-current/doc/roadmaps/mess

$NetBSD: mess,v 1.2 2017/01/14 20:50:15 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.

The first step on this is to disentangle the buffer cache
(buffercache(9)) from the buffer I/O path (bufferio(9)) -- right now
they both abusively share the same struct buf.

 - 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)