1# $NetBSD: ROADMAP,v 1.23 2008/08/04 15:37:05 simonb Exp $ 2 3*** THIS FILE IS OBSOLETE *** 4 5Although many of the projects in this file are still current and 6valid, roadmap information is now stored in the src/doc/roadmaps 7directory. 8 9This file is temporarily retained to allow the information in it to be 10transitioned. 11 12------------------------------------------------------------ 13 14 15A high-level roadmap for NetBSD 16 17This file contains a general map of where we would like to take 18NetBSD over the next N years. It is not highly detailed or overly 19specific about each item. There are several different "TODO" files 20and "NetBSD Projects" lists in various places that contain some 21more detailed plans. This is the framework in which those projects 22and plans are expected to fit. 23 24As this is a volunteer project, there are no specific dates beside 25these items. These items may or may not get picked up in any order, 26and the roadmap may change as technologies and perceived needs 27change. 28 29The roadmap, of course, is constructed in the context of the 30Project's (broad) goals: 31 32 * clean design * stable * fast 33 * clean licensing * portable * interoperable 34 * conformant * commercial-ready * research-ready 35 * hobby-ready 36 37In general, we are headed for: 38 39 * "State of the art" tools (current (and stable) GNU tools, 40 addition of Solaris's dtrace or similar functionality, kernel 41 core dumps on all platforms and post-mortem analysis tools, 42 performance analysis tools with support for hardware assists 43 like PMCs) 44 45 * Support for all devices without encumbered code 46 47 * Managed growth of the base system 48 49 * Minimal GPL / LGPL code in the base system 50 51 * Maximal performance without compromising portability 52 53 * "State of the art" technology in the kernel and userland 54 55 * No bugs, no security vulnerabilities 56 57 * In combination with pkgsrc, a complete system for a variety 58 of users, administrators, and researchers: desktops, embedded 59 devices, servers, workstations, and portables 60 61This is, by no means, a comprehensive list, and purposefully aggressive. 62One of the many challenges will be to achieve excellence in each arena 63we tackle and not settle for being a "jack of all trades, master of none." 64 65The following, more specific, items are divided into rough categories: 66 1. Platform independent kernel 67 2. Platform independent userland 68 3. Platform dependent kernel 69 4. Platform dependent userland 70 5. Other 71 72If you'd like to take on a project, please record your name/email, 73the date that you're claiming a project (or part of a project--if 74a part, please specify the part), and an expected completion date. 75This will hopefully avoid both duplication of effort and too many 76or too-extended stalls. 77 78PLEASE NOTE THAT THIS IS A VOLUNTEER PROJECT, AND THAT NONE OF THESE 79RELEASE VERSIONS, OR NAMES, IS A GUARANTEE OF THE FUNCTIONALITY BEING 80COMPLETE OR EVEN STARTED. INTERESTED PARTIES SHOULD CONTACT 81 82 core@NetBSD.org 83 84FOR MORE INFORMATION. 85 86 871. Platform independent kernel 88============================== 89aa. Scheduler works 90 Separation of context switching and thread scheduling. 91 Responsible: yamt 92 ETA: 5.0 (yamt-idlelwp branch) 93 Generic scheduler API for modular implementations. 94 Responsible: dsieger 95 ETA: 5.0 (merged in yamt-idlelwp branch) 96 New scheduler supporting POSIX Real-time features, CPU affinity and 97 having a better support for MP systems. 98 Responsible: rmind 99 ETA: 5.0 100 101ab. Reduction of the giant lock 102 There are several proposals for the best way forward on this, but 103 we really need a couple of people with time to step forward and 104 lead us here. 105 Responsible: ad 106 ETA: 5.0 (vmlocking2 branch) 107 108ac. Expansion of wedge support 109 Complete the development of wedges and retire disklabels except 110 where needed for compatibility. 111 Responsible: thorpej (possibly) 112 ETA: 5.0 113 114ad. Volume management 115 Allow us to grow, shrink, and move partitions (and, where possible, 116 filesystems). 117 Responsible: TBD 118 ETA: ? 119 120ae. High-performance, maybe log-based, journalled fs w/ snapshot support 121 Addition of logs, journals, and snapshots to FFS is a lot, another 122 filesystem could be cleaner and faster. 123 Responsible: simonb 124 ETA: 5.0 (journaling + snapshots don't work together yet though) 125 126af. Expansion of ieee1394 support 127 Where possible, fully support DV, disk, and network devices. 128 Responsible: TBD 129 ETA: Preliminary firewire support is in 4.0 130 131ag. Generic device hotplug support 132 Support hotplug of all devices and busses that support it. This 133 should be divided into subcategories and does cross over some into 134 platform-dependent areas. SATA, SCSI, FC, USB, Firewire, 135 PCI (PCI-X, and PCI-Express), etc. There is some rudimentary 136 support present, but it is far from comprehensive. 137 Responsible: bouyer 138 ETA: ? 139 140ah. Suspend and resume support 141 We should be able to fully use suspend and resume on PCs, macppc, 142 and anyone else who supports it in hardware (sparc, hpcsh, hpcarm, etc). 143 Responsible: jmcneill, joerg 144 ETA: 5.0 145 146ai. Complete support for LWPs 147 There are still vestiges of the kernel that predate LWPification 148 and should be updated. [ What other than ktrace? ] 149 Responsible: darrenr, skrll, christos did ktrace-lwp 150 ETA: 4.0 151 152aj. PTHREAD_CONCURRENCY > 1 support 153 A single process that uses threads should be able to reliably 154 use more than one CPU. 155 Responsible: ad 156 ETA: 5.0 (1:1 pthread come with newlock2) 157 158ak. AIO support 159 POSIX aio_*() with full support for Asynchronous I/O (AIO) in the 160 kernel. 161 Responsible: rmind 162 ETA: 5.0 163 164al. Modern parallel port support 165 Complete support for bidirectional and "advanced" functionality 166 from parallel ports. 167 Responsible: jdolecek 168 ETA: ? 169 170am. NFSv4 171 Bring our NFS up to current standards. 172 Responsible: TBD 173 ETA: ? 174 175an. Update the locking mechanisms in the kernel 176 This requires some platform support. A good bit of work is on the 177 now-archaic "newlock" branch, from thorpej. It requires some 178 overhaul of cpu_switch/scheduler so that mutex_*(9) and ltsleep(9) 179 can interlock. 180 Responsible: ad 181 ETA: 5.0 (newlock2) 182 183ao. Review TCP/IP developments 184 Fix NewReno 185 Responsible: mycroft 186 ETA: 3.0 187 Add SACK support to the kernel. 188 Responsible: kurahone 189 ETA: 3.0 190 Add ECN support to the kernel. 191 Responsible: rpaulo 192 ETA: 5.0 193 Look into other "recent" and current TCP/IP research. Adapt our stack 194 to the more modern world. 195 Responsible: TBD 196 ETA: ? 197 198ap. Kernel linker (ala FreeBSD's kld) 199 Responsible: TBD 200 ETA: ? 201 202aq. CARP/VRRP 203 Functionality is great, but there might be some concern here over 204 Cisco patents. 205 Responsible: liamfoy 206 ETA: 4.0 207 208ar. UDF filesystem support 209 OpenBSD has recently added this. 210 Responsible: reinoud 211 ETA: 4.0 212 213as. RAIDFrame support for 3-way RAID 1 214 Responsible: TBD 215 ETA: ? 216 217at. RAIDFrame support for RAID 6 218 Responsible: oster 219 ETA: 5.0? 220 221au. More modern drivers 222 We lack support for a number of more modern devices (PCI-Express, 223 RAID cards, etc.) that are supported on other open source OSes. 224 Responsible: TBD 225 ETA: ? 226 227av. iSCSI initiator support 228 We should be able to use iSCSI volumes. 229 Responsible: agc 230 ETA: 5.0 231 232aw. Run-time changeable limits to SysV IPC 233 Some of the limits for SysV IPC are hardcoded in the kernel 234 configuration--these should be changable via sysctl. 235 Responsible: rmind 236 ETA: 4.0 237 238ax. NUMA support 239 To achieve this goal, the CPU scheduler should be modified to take into 240 account the distances and grouping of CPUs. Also, support of memory 241 blocks should be implemented in the VM subsystem. 242 Responsible: TBD 243 ETA: ? 244 2452. Platform independent userland 246================================ 247aa. Keep up with the X world 248 Track X.org progress. Maintain existing XFree86. 249 Responsible: a cast of thousands 250 ETA: ongoing 251 252ab. Reentrant libraries 253 Make sure that all libraries are re-entrant and usable for threaded 254 applications. 255 Responsible: ginsbach and others 256 ETA: 5.0? 257 258ac. gcc updates 259 This requires some work to rework the gcc4 builds to work with BSD 260 make(1) or update BSD make(1) or consider the unthinkable. 261 Responsible: mrg, matt 262 ETA: 4.0 263 264ad. gdb updates 265 Responsible: skrll 266 ETA: 5.0 267 268ae. binutils updates 269 Probably go along with gdb updates. 270 Responsible: skrll 271 ETA: 4.0 272 273af. Better post-mortem debugging tools 274 It would be useful to have something between ps/*stat/etc. and 275 gdb with a core file. Something, perhaps, like SysV(?) crash(8). 276 Responsible: TBD 277 ETA: ? 278 279ag. Better 802.11 utilities and support 280 To truly support mobile users, we need better support for scanning 281 for base stations and affiliating with them. 282 Responsible: dyoung, skrll, scw and others 283 ETA: 4.0 284 285ah. Internationalization 286 Citrus, wide-char curses (SoC integration?), collation, localized 287 printf with positional parameter support, time & currency 288 support, etc. NetBSD has a global user and developer base and 289 our i18n support should reflect that. 290 (a) Support cond. printf fmt. 4.0 will have vfwprintf with 291 positional parameter support; 5.0 will have vfprintf with 292 positional parameter support. 293 Responsible: christos 294 ETA: 5.0 295 (b) Support LC_COLLATE 296 (c) mklocale(1) -> localedef(1) 297 (d) wchar_t in C++ 298 (e) i18nize userland commands 299 (f) in-kernel iconv 300 Responsible: TBD 301 ETA: ? 302 303ai. System packages 304 In some fashion, we need to support system packages. This is at 305 least to allow for sane binary audits and binary patches. 306 Responsible: apb 307 ETA: 4.0 308 309aj. Provide support for binary packages in install 310 We should have an integrated install that can install a desktop as 311 functional as other free operating systems. Without sacrificing 312 the quick and clean basic installs that we have now. An extension 313 of sysinst might fit the bill. Or a tool that's both invoked by 314 sysinst and available on a running system, e.g. pkgsrc-wip/pkg_select. 315 Responsible: agc and others 316 ETA: 4.0 317 318ak. Native signing/privacy software 319 This could be BPG (from SoC) or openpgp-sdk. 320 Responsible: agc, cjs and others 321 ETA: 4.0? 322 323al. Userland version identification 324 What binaries are installed? Who really knows? This relates at 325 least somewhat to (ai). 326 Responsible: TBD 327 ETA: ? 328 3293. Platform dependent kernel 330============================ 331aa. Move evb ports to evb* if they're not already there (sandpoint) 332 The existing evb* ports are kind of catch-all ports for eval boards. 333 Some of the existing non-evb* ports really belong in the evb* category. 334 Responsible: TBD 335 ETA: ? 336 337ab. m68k ports need to share more code 338 Some progress has been made here in recent years, but there is more 339 work to be done. 340 Responsible: TBD 341 ETA: ? 342 343ac. Kernel core dump support for all platforms 344 Some platforms (PowerPC ports, ARM ports, etc.) don't have full 345 support for kernel core dumps and post-mortem debugging through 346 libkvm. This should be updated. 347 Responsible: TBD 348 ETA: ? 349 350ad. NDIS 351 Support for binary network drivers on x86 platforms. 352 Responsible: rittera 353 ETA: 4.0 354 3554. Platform dependent userland 356============================== 357ab. m68k should be able to share sets 358 Some progress has been made here in recent years, but there is more 359 work to be done. 360 Responsible: TBD 361 ETA: ? 362 3635. Other 364======== 365aa. More and better regression tests 366 The suite of tests that we have now is limited. We should expand 367 these and provide systems (or manage a volunteer pool?) to run the 368 tests on -current and release branches on a variety of platforms. 369 We also need to migrate all the tests that currently live in 370 'regress' to 'tests' so that they can make use of ATF. 371 ( Need to virtualize some with qemu or similar? ) 372 Responsible: jmmv 373 ETA: 5.0 should have most of regress converted 374 375ab. Native Java on multiple platforms 376 Getting i386, amd64, sparc64, and PowerPC would be a good start, 377 although PowerPC will require more work. We have the go-ahead, 378 but we need the people to work on it. 379 Responsible: the Java porting crew 380 ETA: ? 381 382ac. Power control framework 383 Related to suspend/resume support, we should have some framework 384 for dynamically stepping processor speed, controlling fans, shutting 385 down and/or powering subsystems to conserve power and keep the system 386 with thermal limits. 387 Responsible: TBD 388 ETA: ? 389