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