224 lines
8.5 KiB
Plaintext
224 lines
8.5 KiB
Plaintext
$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)
|