[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: /about/ROADMAP

Subject: Re: /about/ROADMAP
From: 航李访当<kei_sun@ba2.so-net.ne.jp>
To: "话呜扛( Miwa Susumu )"<miwarin@gmail.com>
Date: Mon, 4 Jan 2010 13:21:12 +0900
Message-Id: <4EDE8B54-22FA-43A8-8AF6-2651A0F08D73@ba2.so-net.ne.jp>
Cc: www-changes-ja <www-changes-ja@jp.netbsd.org>
Delivered-To: mailing list www-changes-ja@jp.netbsd.org
Mailing-List: contact www-changes-ja-help@jp.netbsd.org; run by ezmlm-idx
嵒愳偱偡丅
崱擭傕傛傠偟偔偍婅偄偟傑偡丅
仸実懷偐傜側偺偱撉傒擄偐偭偨傜偡傒傑偣傫丅
暘検偑懡偔偰戝曄偱偡偹丅偍旀傟條偱偡丅嶲峫栿傪捛婰偟傑偟偨丅偛棗偔偩偝 
偄丅

On 31 Dec 2009, at 23:21, 嶰椫怶( Miwa Susumu ) <miwarin@gmail.com>  
wrote:

> 嶰椫偱偡丅
>
> 擭枛偱偡偑丅
> 東栿傪廋惓偟傑偟偨丅
> (complete偲偐add側偳偗偭偙偆娫堘偭偰偄偨偺偱)
> 東栿偼儊乕儖嵟屻偵彂偒傑偟偨丅
>
> 偨偩丄偳偆偟偰傕暘偐傜側偄売強偑偁傞偺偱嫵偊偰偔偩偝偄丅
> ROADMAP偺慜偺傎偆偵偁傞埲壓偺暥復側傫偱偡偑....
>
> This will hopefully avoid both duplication of effort and too many
> or too-extended stalls.
>
> 偙偙偱偄偆乽too many or too-extended stalls乿偼
> 偮傑傝掲傔愗傝偑庣傜傟側偄偙偲偵偮偄偰怗傟偰偄傞偺偱偟傚偆偐丠

仸偦偆偱偡偹丅偙傫側姶偠偱偟傚偆偐丅

偙傟偵傛傝丄偆傑偔峴偗偽搘椡偺廳暋偲丄搙乆傑偨偼挿婜娫僾儘僕僃僋僩偑掆懾 
偡傞偙偲偺椉曽傪旔偗傞偙偲偑偱偒傞偱偟傚偆丅

>>>>> 偙偙偐傜
> #    %NetBSD: ROADMAP,v 1.23 2008/08/04 15:37:05 simonb Exp %
>
> A high-level roadmap for NetBSD
> NetBSD 偺忋埵奣擮儘乕僪儅僢僾
>
>
> This file contains a general map of where we would like to take
> NetBSD over the next N years.  It is not highly detailed or overly
> specific about each item.  There are several different "TODO" files
> and "NetBSD Projects" lists in various places that contain some
> more detailed plans.  This is the framework in which those projects
> and plans are expected to fit.
> 偙偺僼傽僀儖偼師偺 N 擭娫偱 NetBSD 傪偳偺傛偆偵偟偨偄偐偲偄偆儘乕僪儅僢 
> 僾傪娷傫偱偄傑偡丅

> 偙偺儘乕僪儅僢僾偺奺崁栚偼丄傑偭偨偔徻嵶偵彂偐傟偰偄側偄偐丄傑偨偼偁傑 
> 傝偼偭偒傝偲彂偄偰偄傑偣傫丅

偁傑傝徻嵶偵彂偐傟偰偍傜偢丄傑偨屄暿偺崁栚偵偼怺擖傝偟偰偄傑偣傫丅

> 偄偔偮偐偺堎側偭偨 "TODO" 僼傽僀儖偲 "NetBSD僾儘僕僃僋僩" 偺儕僗僩偑暿 
> 偺応強偵偁傝丄偦傟傜偵偼傛傝徻嵶側寁夋偑娷傑傟偰偄傑偡丅

> 偙偺儘乕僪儅僢僾偼丄偦傟傜偺僾儘僕僃僋僩偲寁夋偵崌偆偙偲偑婜懸偱偒傞僼 
> 儗乕儉儚乕僋偱偡丅

偦傟傜偺僾儘僕僃僋僩偲寁夋偼丄偙偺儘乕僪儅僢僾偺榞慻傒偵増偭偰幚巤偝傟傞 
梊掕偱偡丅

仸偐側傝堄栿偱偡偑乧乧

>
>
> As this is a volunteer project, there are no specific dates beside
> these items.  These items may or may not get picked up in any order,
> and the roadmap may change as technologies and perceived needs
> change.
> 偙傟偼儃儔儞僥傿傾僾儘僕僃僋僩側偺偱丄偙傟傜偺崁栚偵婜擔偼偁傝傑偣傫丅
> 偙傟傜偺崁栚偼弴晄摨偵拝庤偝傟傞偐傕偟傟側偄偟丄拝庤偝傟側偄偐傕偟傟傑 
> 偣傫丅
> 偦偟偰丄媄弍偲僯乕僘偺曄壔偵墳偠偰丄儘乕僪儅僢僾偼曄壔偡傞偐傕偟傟傑偣 
> 傫丅
>
>
> The roadmap, of course, is constructed in the context of the
> Project's (broad) goals:
> 傕偪傠傫儘乕僪儅僢僾偼 NetBSD 僾儘僕僃僋僩偺暆峀偄栚昗偵偁傢偣偰峔惉偝 
> 傟傑偡:
>
>   * clean design        * stable        * fast
>   * 偒傟偄側愝寁        * 寴楽惈        * 懍偝
>   * clean licensing    * portable        * interoperable
>   * 偒傟偄側儔僀僙儞僗    * 堏怉惈        * 塣梡惈

憡屳塣梡惈偑椙偄偱偡丅

>   * conformant        * commercial-ready    * research-ready
>   * 揔崌惈        * 彜梡偱偺棙梡    * 尋媶偱偺棙梡
>   * hobby-ready
>   * 庯枴偱偺棙梡
>
> In general, we are headed for:
> 堦斒揑偵丄巹偨偪偺僑乕儖偼埲壓偺傛偆側傕偺偱偡丅
>   * "State of the art" tools (current (and stable) GNU tools,
>     addition of Solaris's dtrace or similar functionality, kernel
>     core dumps on all platforms and post-mortem analysis tools,
>     performance analysis tools with support for hardware assists
>     like PMCs)
>   * 嵟崅悈弨偺僣乕儖 (current偺 (偦偟偰stable偺) GNU僣乕儖丄Solaris  
> 偺 dtrace
> 傑偨偼摨掱搙偺婡擻惈偺捛壛丄偡傋偰偺僾儔僢僩僼僅乕儉偺僇乕僱儖僐傾僟儞 
> 僾偲帠屻暘愅僣乕儖丄PMC
> 偺傛偆偵僴乕僪僂僃傾傪梡偄偨僷僼僅乕儅儞僗暘愅僣乕儖)
>
>   * Support for all devices without encumbered code
>   * 尃棙偮偒僐乕僪柍偟偵偡傋偰偺僨僶僀僗偺僒億乕僩偡傞偙偲
>
>   * Managed growth of the base system
>   * 婎杮僔僗僥儉偺惉挿娗棟
>
>   * Minimal GPL / LGPL code in the base system
>   * 婎杮僔僗僥儉偺嵟彫検偺GPL / LGPL僐乕僪
>
>   * Maximal performance without compromising portability
>   * 堏怉惈傪懝側偆偙偲偺側偄嵟崅惈擻
>
>   * "State of the art" technology in the kernel and userland
>   * 嵟崅悈弨偺僇乕僱儖偲儐乕僓乕儔儞僪
>
>   * No bugs, no security vulnerabilities
>   * 僶僌側偟丄僙僉儏儕僥傿惼庛惈側偟
>
>   * In combination with pkgsrc, a complete system for a variety
>     of users, administrators, and researchers: desktops, embedded
>     devices, servers, workstations, and portables
>   * pkgsrc (條乆側儐乕僓乕丄娗棟幰丄尋媶幰偺偨傔偺姰慡側僔僗僥儉) 偲寢 
> 崌偟偰: 僨僗僋僩僢僾丄慻崬僨僶僀僗丄僒乕僶乕丄儚乕僋僗僥乕僔儑儞丄億乕 
> 僞僽儖

  * pkgsrc偲慻傒崌傢偣偰丄條乆側儐乕僓乕丄娗棟幰丄尋媶幰偺偨傔偺姰慡側僔 
僗僥儉: 僨僗僋僩僢僾丄慻傒崬傒僨僶僀僗丄僒乕僶乕丄儚乕僋僗僥乕僔儑儞丄 
億乕僞僽儖婡婍

>
>
> This is, by no means, a comprehensive list, and purposefully  
> aggressive.
> One of the many challenges will be to achieve excellence in each arena
> we tackle and not settle for being a "jack of all trades, master of  
> none."
> 偙偺儕僗僩偼曪妵揑偱傕側偔丄愊嬌揑偵庢傝慻傓偙偲傪堄枴偡傞傢偗偱傕偁傝 
> 傑偣傫丅

偙偺儕僗僩偼慡偔傕偭偰曪妵揑偱偼側偔丄傑偨堄恾偟偰栰怱揑偵側偭偰偄傑偡丅

> 偙傟傜偺僑乕儖偺偆偪 1
> 偮偼丄変乆偑庢傝慻傓奺乆偺暘栰偱桪傟偨傕偺傪嶌傞偙偲偱偁傝丄乽婍梡昻 
> 朢乿偵側傝偨偄傢偗偱偼偁傝傑偣傫丅
>
>
> The following, more specific, items are divided into rough categories:
>   1. Platform independent kernel
>   2. Platform independent userland
>   3. Platform dependent kernel
>   4. Platform dependent userland
>   5. Other
> 屻弎偡傞嬶懱揑側崁栚偼丄偍偍偞偭傁側僇僥僑儕乕偵暘偗傜傟傑偡:
>   1. 僾儔僢僩僼僅乕儉偐傜撈棫偟偨僇乕僱儖
>   2. 僾儔僢僩僼僅乕儉偐傜撈棫偟偨儐乕僓乕儔儞僪
>   3. 僾儔僢僩僼僅乕儉偵埶懚偡傞僇乕僱儖
>   4. 僾儔僢僩僼僅乕儉偵埶懚偡傞儐乕僓乕儔儞僪
>   5. 偦偺懠
>
> If you'd like to take on a project, please record your name/email,
> the date that you're claiming a project (or part of a project--if
> a part, please specify the part), and an expected completion date.
> This will hopefully avoid both duplication of effort and too many
> or too-extended stalls.
>
> 偁側偨偑僾儘僕僃僋僩傪堷偒庴偗偨偄偲巚偆側傜偽丄偁側偨偺柤慜/揹巕儊乕 
> 儖 (偁側偨偑庡挘偟偰偄傞僾儘僕僃僋僩
> (僾儘僕僃僋僩偺堦晹晹暘側傜偽丄偦偺晹暘傪巜掕偟偰偔偩偝偄)
> 偲婜懸偝傟傞姰惉擔傪婰弎偟偰偔偩偝偄丅偙傟偼廳暋偟偨嶌嬈偲丄傛偔偁傞墑 
> 婜偺偨傔偺岆杺壔偟傪旔偗傞偨傔偱偡丅
>
>
> PLEASE NOTE THAT THIS IS A VOLUNTEER PROJECT, AND THAT NONE OF THESE
> RELEASE VERSIONS, OR NAMES, IS A GUARANTEE OF THE FUNCTIONALITY BEING
> COMPLETE OR EVEN STARTED.  INTERESTED PARTIES SHOULD CONTACT
>
>       core@NetBSD.org
>
> 偙傟偑儃儔儞僥傿傾僾儘僕僃僋僩偱偁傝丄偳偺儕儕乕僗僶乕僕儑儞 (傑偨偼柤 
> 慜)
> 傕姰椆偟偨偐丄傑偨偼拝庤偝傟偨偙偲傪曐徹偟偰偄傞傢偗偱偼側偄偙偲偵拲堄 
> 偟偰偔偩偝偄丅嫽枴偑偁傞曽偼埲壓偵楢棈偟偰偔偩偝偄丅
>
>       core@NetBSD.org
>
>
> FOR MORE INFORMATION.
> 徻嵶側忣曬丅
>
> 1. Platform independent kernel
> 1. 僾儔僢僩僼僅乕儉偐傜撈棫偟偨僇乕僱儖
> ==============================
> aa. Scheduler works
>   Separation of context switching and thread scheduling.
>   Responsible: yamt
>   ETA: 5.0 (yamt-idlelwp branch)
>   Generic scheduler API for modular implementations.
>   Responsible: dsieger
>   ETA: 5.0 (merged in yamt-idlelwp branch)
>   New scheduler supporting POSIX Real-time features, CPU affinity and
>   having a better support for MP systems.
>   Responsible: rmind
>   ETA: 5.0
> aa. 僗働僕儏乕儔婡擻
>   僐儞僥僉僗僩僗僀僢僠偺暘棧偲僗儗僢僪偺僗働僕儏乕儕儞僌丅
>   愑擟幰: yamt
>   ETA: 5.0 (yamt-idlelwp 僽儔儞僠)
>   儌僕儏乕儖幚憰偺偨傔偺斈梡僗働僕儏乕儔 API丅
>   愑擟幰: dsieger
>   ETA: 5.0 (yamt-idlelwp 僽儔儞僠偵儅乕僕)
>   怴偟偄僗働僕儏乕儔 (POSIX 儕傾儖僞僀儉婡擻偲丄CPU 恊榓惈偲丄MP 僔僗僥 
> 儉偺偨傔偺傛傝椙偄僒億乕僩)
>   愑擟幰: rmind
>   ETA: 5.0
>
> ab. Reduction of the giant lock
>   There are several proposals for the best way forward on this, but
>   we really need a couple of people with time to step forward and
>   lead us here.
>   Responsible: ad
>   ETA: 5.0 (vmlocking2 branch)
> ab. 僕儍僀傾儞僩儘僢僋偺嶍尭
>   偙偺偨傔偺嵟慞偺曽朄偑偄偔偮偐採埬偝傟偰偄傑偡丅傢偢偐側恖悢偱傕慜恑 
> 偟丄偙偺僑乕儖傊偨偳傝拝偔偙偲傪昁梫偲偟偰偄傑偡丅
>   愑擟幰: ad
>   aETA: 5.0 (vmlocking2 僽儔儞僠)
>
>
> ac. Expansion of wedge support
>   Complete the development of wedges and retire disklabels except
>   where needed for compatibility.
>   Responsible: thorpej (possibly)
>   ETA: 5.0
> ac. wedge 僒億乕僩偺奼戝
>   wedge 偺奐敪傪姰椆偝偣偰偔偩偝偄丅偦偟偰丄屳姺惈偵昁梫偑偁傞偺傪彍偄 
> 偰 disklabels 傪堷戅偝偣偰偔偩偝偄丅
>   愑擟幰: thorpej (偍偦傜偔)
>   ETA: 5.0
>
>
> ad. Volume management
>   Allow us to grow, shrink, and move partitions (and, where possible,
>   filesystems).
>   Responsible: TBD
>   ETA: ?
> ad. 儃儕儏乕儉娗棟
>   僷乕僥傿僔儑儞傪奼挘丄弅彫丄堏摦偱偒傞傛偆偵偟偰偔偩偝偄 (壜擻側尷傝 
> 僼傽僀儖僔僗僥儉偑偍偙側偆偺偑偄偄偱偟傚偆)
>   愑擟幰: TBD
>   ETA: ?

仸埲壓丄僥乕儅偺尨暥偼柦椷宍偱偡偑丄擔杮屻偺応崌偼晛捠偺懱尵巭傔(乣偡傞偙 
偲)偑帺慠偐傕偟傟傑偣傫丅

(壜擻偱偁傟偽丄僼傽僀儖僔僗僥儉偵偮偄偰傕摨條偵)

  愑擟幰: 枹掕

>
>
> ae. High-performance, maybe log-based, journalled fs w/ snapshot  
> support
>   Addition of logs, journals, and snapshots to FFS is a lot, another
>   filesystem could be cleaner and faster.
>   Responsible: simonb
>   ETA: 5.0 (journaling + snapshots don't work together yet though)
> ae. 僗僫僢僾僒億乕僩偑偁傞崅惈擻偺丄偦偟偰丄偨傇傫儘僌儀乕僗偺僕儍乕僫 
> 儖僼傽僀儖僔僗僥儉
>   FFS 傊偺捛壛偡傞儘僌婡擻丄僕儍乕僫儕儞僌婡擻丄僗僫僢僾僔儑僢僩婡擻偼 
> 偨偔偝傫偁傝傑偡丅暿偺僼傽僀儖僔僗僥儉偱偼傕偭偲鉟楉偱懍偄偐傕偟傟傑偣 
> 傫丅

FFS偵儘僌丄僕儍乕僫儖丄僗僫僢僾僔儑僢僩婡擻傪捛壛偡傞偺偼堦戝帠偱偡丅偍偦 
傜偔暿偺僼傽僀儖僔僗僥儉側傜傛傝鉟楉偱懍偄偱偟傚偆丅

>   愑擟幰: simonb
>   ETA: 5.0 (傕偭偲傕丄僕儍乕僫儕儞僌偲僗僫僢僾偺慻傒崌傢偣偼丄傑偩摨帪 
> 偵婡擻偟偰偄傑偣傫)
>
>
> af. Expansion of ieee1394 support
>   Where possible, fully support DV, disk, and network devices.
>   Responsible: TBD
>   ETA: Preliminary firewire support is in 4.0
> af. ieee1394僒億乕僩偺奼挘
>   壜擻側尷傝 DV丄僨傿僗僋丄僱僢僩儚乕僋僨僶僀僗傪僒億乕僩偟傑偡丅
>   愑擟幰: TBD
>   ETA: 4.0 偱偼 Preliminary FireWire 傪僒億乕僩偟偰偄傑偡丅

ETA: 4.0偱偼FireWire僒億乕僩偺弨旛偑偝傟偰偄傑偡丅

>
> ag. Generic device hotplug support
>   Support hotplug of all devices and busses that support it.  This
>   should be divided into subcategories and does cross over some into
>   platform-dependent areas.  SATA, SCSI, FC, USB, Firewire,
>   PCI (PCI-X, and PCI-Express), etc.  There is some rudimentary
>   support present, but it is far from comprehensive.
>   Responsible: bouyer
>   ETA: ?
> ag. 斈梡僨僶僀僗 hotplug 僒億乕僩
>   偡傋偰偺僨僶僀僗偲偦偺僶僗偺 hotplug 傪僒億乕僩偟偰偄傑偡丅
>   偙傟偼丄僒僽僇僥僑儕偵暘妱偝傟傞傋偒偱偁傝丄偄偔偮偐偺僾儔僢僩僼僅乕 
> 儉偵埶懚偡傞椞堟傪挻偊傑偣傫丅
>   SATA丄SCSI丄FC丄USB丄FireWire丄PCI (PCI X 偲 PCI-Express)

偙傟偼僒僽僇僥僑儕乕偵暘妱偝傟傞傋偒偱偁傝丄SATA丄SCSI丄FC丄USB丄 
FireWire丄 PCI (PCI X 偲 PCI-Express)側偳偺応崌偼丄僾儔僢僩僼僅乕儉偵埶懚 
偡傞椞堟偵傑偨偑傝傑偡丅
偄偔偮偐偺乣

> 側偳丄偄偔偮偐偺弶曕揑側僒億乕僩偑偁傝傑偡偑丄偦傟偼慡偔曪妵揑偱偼偁傝 
> 傑偣傫丅
>
>   愑擟幰: bouyer
>   ETA: ?
>
> ah. Suspend and resume support
>   We should be able to fully use suspend and resume on PCs, macppc,
>   and anyone else who supports it in hardware (sparc, hpcsh, hpcarm,  
> etc).
>   Responsible: jmcneill, joerg
>   ETA: 5.0
> ah. 僒僗儁儞僪偲儕僕儏乕儉僒億乕僩
>   PC丄MacPPC丄偦偟偰僒僗儁儞僪偲儕僕儏乕儉傪僒億乕僩偟偰偄傞僴乕僪僂僃 
> 傾 (sparc丄hpcsh丄hpcarm側偳) 側傜偽姰慡偵巊梡偱偒傞偼偢偱偡丅
>   愑擟幰: jmcneill丄joerg
>   ETA: 5.0
>
> ai. Complete support for LWPs
>   There are still vestiges of the kernel that predate LWPification
>   and should be updated.  [ What other than ktrace? ]
>   Responsible: darrenr, skrll, christos did ktrace-lwp
>   ETA: 4.0
> ai. LWP 僒億乕僩傪姰椆偝偣偰偔偩偝偄
>   LWPification 偺偙傠偺柤巆傝偑傑偩僇乕僱儖偵偁傞偺偱丄傾僢僾僨乕僩偡傋 
> 偒偱偡(ktrace 埲奜?)

LWP壔埲慜偺僐乕僪偺柤巆偑傑偩僇乕僱儖偵巆偭偰偍傝丄偙傟偼傾僢僾僨乕僩偡傋 
偒偱偡丅(ktrace埲奜壗偑偁傞?)

>   愑擟幰: darrenr丄skrll丄christos 偼 ktrace-lwp 傪偟傑偟偨丅
>   ETA: 4.0
>
> aj. PTHREAD_CONCURRENCY > 1 support
>   A single process that uses threads should be able to reliably
>   use more than one CPU.
>   Responsible: ad
>   ETA: 5.0  (1:1 pthread come with newlock2)
> aj. PTHREAD_CONCURRENCY > 1 僒億乕僩
>   1 僾儘僙僗偑妋幚偵 1 偮埲忋偺 CPU 傪巊梡偱偒傞傛偆偵偡傞昁梫偑偁傝傑 
> 偡丅
>   愑擟幰: ad
>   ETA: 5.0 (1:1 pthread偵偼丄newlock2 偼偮偄偰棃傑偡)
>
>
> ak. AIO support
>   POSIX aio_*() with full support for Asynchronous I/O (AIO) in the
>   kernel.
>   Responsible: rmind
>   ETA: 5.0
> ak. AIO 僒億乕僩
>   POSIX aio_*() 偵傛傞僇乕僱儖偱偺姰慡側旕摨婜 I/O (AIO) 僒億乕僩
>   愑擟幰: rmind
>   ETA: 5.0
>
>
> al. Modern parallel port support
>   Complete support for bidirectional and "advanced" functionality
>   from parallel ports.
>   Responsible: jdolecek
>   ETA: ?
> al. 儌僟儞側僷儔儗儖億乕僩僒億乕僩
>   憃曽岦僷儔儗儖億乕僩偲丄峏側傞僷儔儗儖億乕僩偺僒億乕僩傪姰椆偝偣偰偔 
> 偩偝偄丅
>   愑擟幰: jdolecek
>   ETA: ?
>
>
> am. NFSv4
>   Bring our NFS up to current standards.
>   Responsible: TBD
>   ETA: ?
> am. NFSv4
>   尰嵼偺 NFS 偺婎弨傑偱忋偘偰偔偩偝偄丅
>   愑擟幰: TBD
>   ETA: ?
>
> an. Update the locking mechanisms in the kernel
>   This requires some platform support.  A good bit of work is on the
>   now-archaic "newlock" branch, from thorpej.  It requires some
>   overhaul of cpu_switch/scheduler so that mutex_*(9) and ltsleep(9)
>   can interlock.
>   Responsible: ad
>   ETA: 5.0  (newlock2)
> an. 僇乕僱儖偺儘僢僋婡峔傪傾僢僾僨乕僩偟偰偔偩偝偄
>   偙傟偼偄偔偮偐偺僾儔僢僩僼僅乕儉僒億乕僩傪昁梫偲偟傑偡丅
>   thorpej 偵傛傞 "newlock" 僽儔儞僠偱偢偭偲嶌嬈偟偰偄傑偡丅

thorpel偵傛傞崱傗屆傔偐偟偄newlock僽儔儞僠偵椙偄嶌嬈寢壥偑偁傝傑偡丅
偙傟偼乣

>   mutex_*(9) 偲 ltsleep(9) 偑楢摦偡傞偨傔偵 cpu_switch/scheduler 偺僆乕 
> 僶乕儂乕儖偑偄偔偮偐昁梫偱偡丅
>   愑擟幰: ad
>   ETA: 5.0 (newlock2)
>
>
> ao. Review TCP/IP developments
>   Fix NewReno
>   Responsible: mycroft
>   ETA: 3.0
>   Add SACK support to the kernel.
>   Responsible: kurahone
>   ETA: 3.0
>   Add ECN support to the kernel.
>   Responsible: rpaulo
>   ETA: 5.0
>   Look into other "recent" and current TCP/IP research. Adapt our  
> stack
>   to the more modern world.
>   Responsible: TBD
>   ETA: ?
> ao. TCP/IP 奐敪偺儗價儏乕
>   NewReno 傪僼傿僢僋僗偟偰偔偩偝偄丅
>   愑擟幰: mycroft
>   ETA: 3.0
>   SACK 僒億乕僩傪僇乕僱儖偵捛壛偟偰偔偩偝偄丅
>   愑擟幰: kurahone
>   ETA: 3.0
>   ECN 僒億乕僩傪僇乕僱儖偵捛壛偟偰偔偩偝偄丅
>   愑擟幰: rpaulo
>   ETA: 5.0
>   偦偺懠偺 "recent" 傗嵟怴偺 TCP/IP 偵偮偄偰偺尋媶傪挷傋偰偔偩偝偄丅  
> TCP/IP 僗僞僢僋傪嬤戙揑側幚憰偵彂偒姺偊偰偔偩偝偄丅
>   愑擟幰: TBD
>   ETA: ?
>
> ap. Kernel linker (ala FreeBSD's kld)
>   Responsible: TBD
>   ETA: ?
> ap. 僇乕僱儖儕儞僇 (FreeBSD 桼棃偺 kld)
>   愑擟幰: TBD
>   ETA: ?
>
>
> aq. CARP/VRRP
>   Functionality is great, but there might be some concern here over
>   Cisco patents.
>   Responsible: liamfoy
>   ETA: 4.0
> aq. CARP/VRRP
>   婡擻偼慺惏傜偟偄偱偡偑丄僔僗僐偺摿嫋偵傛傞寽擮偑偄偔偮偐偁傝傑偡丅
>   愑擟幰: liamfoy
>   ETA: 4.0
>
> ar. UDF filesystem support
>   OpenBSD has recently added this.
>   Responsible: reinoud
>   ETA: 4.0
> ar. UDF 僼傽僀儖僔僗僥儉僒億乕僩
>   嵟嬤 OpenBSD 偑懳墳偟傑偟偨丅
>   愑擟幰: reinoud
>   ETA: 4.0
>
>
> as. RAIDFrame support for 3-way RAID 1
>   Responsible: TBD
>   ETA: ?
> as. 3-way RAID 1 偺偨傔偺 RAIDFrame
>   愑擟幰: TBD
>   ETA: ?
>
>
> at. RAIDFrame support for RAID 6
>   Responsible: oster
>   ETA: 5.0?
> at. RAID6 偺偨傔偺 RAIDFrame 僒億乕僩
>   愑擟幰: oster
>   ETA: 5.0?
>
>
> au. More modern drivers
>   We lack support for a number of more modern devices (PCI-Express,
>   RAID cards, etc.) that are supported on other open source OSes.
>   Responsible: TBD
>   ETA: ?
> au. 傕偭偲懡偔偺儌僟儞側僪儔僀僶乕
>   懡偔偺懠偺僆乕僾儞僜乕僗 OS 偱僒億乕僩偝傟偰偄傞儌僟儞側僨僶僀僗  
> (PCI-Express丄RAID僇乕僪側偳) 偑僒億乕僩偝傟偰偄傑偣傫丅
>   愑擟幰: TBD
>   ETA: ?
>
>
> av. iSCSI initiator support
>   We should be able to use iSCSI volumes.
>   Responsible: agc
>   ETA: 5.0
> av. iSCSI 僀僯僔僄乕僞乕僒億乕僩
>   iSCSI 儃儕儏乕儉傪巊梡偱偒傞偼偢偱偡丅

乣巊梡偱偒傞傋偒偱偡丅
仸懠偵傕奩摉晹暘偑壗売強偐偁傝傑偡丅

>   愑擟幰: agc
>   ETA: 5.0
>
>
> aw. Run-time changeable limits to SysV IPC
>   Some of the limits for SysV IPC are hardcoded in the kernel
>   configuration--these should be changable via sysctl.
>   Responsible: rmind
>   ETA: 4.0
> aw. 幚峴帪偵 SysV IPC 偺愝掕抣傪曄峏偡傞
>   SysV IPC 偺偄偔偮偐偺愝掕抣偑僇乕僱儖僐儞僼傿僊儏儗乕僔儑儞偱僴乕僪 
> 僐乕僪偝傟偰偄傑偡丅劅偙傟傜偼sysctl偱曄峏壜擻側偼偢偱偡丅
>   愑擟幰: rmind
>   ETA: 4.0
>
>
> ax. NUMA support
>   To achieve this goal, the CPU scheduler should be modified to take  
> into
>   account the distances and grouping of CPUs.  Also, support of memory
>   blocks should be implemented in the VM subsystem.
>   Responsible: TBD
>   ETA: ?
> ax. NUMA 僒億乕僩
>   偙偺栚昗傪払惉偡傞側傜丄CPU 僗働僕儏乕儔偼丄CPU 偺嫍棧偲僌儖乕僺儞僌 
> 傪峫椂偵擖傟傞傛偆偵曄峏偝傟傞傋偒偱偡丅
>   傑偨丄儊儌儕僽儘僢僋偺僒億乕僩偼 VM 僒僽僔僗僥儉偱幚憰偝傟傞傋偒偱 
> 偡丅
>   愑擟幰: TBD
>   ETA: ?
>
>
> 2. Platform independent userland
> 2. 僾儔僢僩僼僅乕儉偐傜撈棫偟偨儐乕僓乕儔儞僪
> ================================
> aa. Keep up with the X world
>   Track X.org progress.  Maintain existing XFree86.
>   Responsible: a cast of thousands
>   ETA: ongoing
> aa. X 偺曐帩
>   X.org 偺恑捇偵捛廬偟偰偔偩偝偄丅婛懚偺 XFree86 傪堐帩偟偰偔偩偝偄丅
>   愑擟幰: 悢愮恖偺僉儍僗僩
>   ETA: 恑峴拞
>
> ab. Reentrant libraries
>   Make sure that all libraries are re-entrant and usable for threaded
>   applications.
>   Responsible: ginsbach and others
>   ETA: 5.0?
> ab. 儕僄儞僩儔儞僩儔僀僽儔儕
>   僗儗僢僪壔偝傟偨傾僾儕働乕僔儑儞偵偡傋偰偺儔僀僽儔儕偑妋幚偵儕僄儞僩 
> 儔儞僩偱偒傞傛偆偵偟偰偔偩偝偄丅

僗儗僢僪壔偝傟偨傾僾儕働乕僔儑儞偱巊偊傞傛偆偵丄慡偰偺儔僀僽儔儕乕偑妋幚 
偵儕僄儞僩儔儞僩偱偁傞傛偆偵偟偰偔偩偝偄丅

>   愑擟幰: ginsbach 懠
>   ETA: 5.0?
>
>
> ac. gcc updates
>   This requires some work to rework the gcc4 builds to work with BSD
>   make(1) or update BSD make(1) or consider the unthinkable.
>   Responsible: mrg, matt
>   ETA: 4.0
> ac. gcc 傾僢僾僨乕僩
>   gcc4 傪 BSD make(1) 偱摦嶌偡傞傛偆偵偡傞偐丄BSD make(1) 傪傾僢僾僨乕 
> 僩偡傞偐丄傑偨偼憐憸傪愨偡傞嶌嬈偑昁梫偱偡丅
>   愑擟幰: mrg, matt
>   ETA: 4.0
>
>
> ad. gdb updates
>   Responsible: skrll
>   ETA: 5.0
> ad. gdb 傾僢僾僨乕僩
>   愑擟幰: skrll
>   ETA: 5.0
>
>
> ae. binutils updates
>   Probably go along with gdb updates.
>   Responsible: skrll
>   ETA: 4.0
> ae. binutils 傾僢僾僨乕僩
>   偍偦傜偔 gdb 傾僢僾僨乕僩偲嫤椡偟偰嶌嬈偟傑偡丅
>   愑擟幰: skrll
>   ETA: 4.0
>
>
> af. Better post-mortem debugging tools
>   It would be useful to have something between ps/*stat/etc. and
>   gdb with a core file.  Something, perhaps, like SysV(?) crash(8).
>   Responsible: TBD
>   ETA: ?
> af. 傛傝椙偄専巰梡僨僶僢僌僣乕儖
>   ps, *stat, etc 偺娫偵壗偐偁傞偲曋棙偱偡丅偁偲 gdb 偲僐傾僼傽僀儖傕丅

ps/*stat側偳偺僣乕儖偲丄gdb偵僐傾僼傽僀儖偲偺娫偵壗偐偑偁傞偲曋棙偱偟傚 
偆丅
壗偐丄乣

> 偍偦傜偔 SysV(?) 偺 crash(8) 偺傛偆側傕偺偱偡丅
>   愑擟幰: TBD
>   ETA: ?
>
>
> ag. Better 802.11 utilities and support
>   To truly support mobile users, we need better support for scanning
>   for base stations and affiliating with them.
>   Responsible: dyoung, skrll, scw and others
>   ETA: 4.0
> ag. 傛傝椙偄 802.11 儐乕僥傿儕僥傿偲僒億乕僩
>   杮摉偵儌僶僀儖儐乕僓傪僒億乕僩偡傞偨傔偵偼丄儀乕僗僗僥乕僔儑儞傪専嶕 
> 偟偰偦傟傜偵壛擖偱偒傞傛偆偵偡傞偙偲偑昁梫偱偡丅
>   愑擟幰: dyoung丄skrll丄scw丄懠
>   ETA: 4.0
>
> ah. Internationalization
>   Citrus, wide-char curses (SoC integration?), collation, localized
>   printf with positional parameter support, time & currency
>   support, etc.  NetBSD has a global user and developer base and
>   our i18n support should reflect that.
>       (a) Support cond. printf fmt. 4.0 will have vfwprintf with
>       positional parameter support; 5.0 will have vfprintf with
>       positional parameter support.
>       Responsible: christos
>       ETA: 5.0
>       (b) Support LC_COLLATE
>       (c) mklocale(1) -> localedef(1)
>       (d) wchar_t in C++
>       (e) i18nize userland commands
>       (f) in-kernel iconv
>       Responsible: TBD
>       ETA: ?
> ah. 崙嵺壔
>   Citrus丄儚僀僪暥帤懳墳 curses(SoC 偵摑崌丠)丄暥帤徠崌丄埵抲僷儔儊乕 
> 僞乕懳墳偺儘乕僇儔僀僘偝傟偨
> printf僒億乕僩丄帪崗偲捠壿僒億乕僩丄偦偺傎偐丅NetBSD 偵偼僌儘乕僶儖側 
> 儐乕僓乕偲奐敪幰儀乕僗偑偁傝丄偦偟偰 i18n
> 偼偦傟傜傪斀塮偡傋偒偱偡丅
>       (a) Support cond. printf fmt: 4.0 偵偼丄埵抲僷儔儊僞僒億乕僩懳 
> 墳 vfwprintf 偑偁傞偱偟傚偆丅
> 5.0 偵偼丄埵抲僷儔儊僞僒億乕僩偑偁傞 vfprintf 偑偁傞偱偟傚偆丅
>       愑擟幰: christos
>       ETA: 5.0
>       (b) LC_COLLATE僒億乕僩
>       (c) mklocale(1) -> localedef(1)
>       (d) C++ 偵偍偗傞 wchar_t
>       (e) i18n 壔偝傟偨儐乕僓乕儔儞僪僐儅儞僪
>       (f) 僇乕僱儖偵偍偗傞 iconv
>       愑擟幰: TBD
>       ETA: ?
>
>
> ai. System packages
>   In some fashion, we need to support system packages.  This is at
>   least to allow for sane binary audits and binary patches.
>   Responsible: apb
>   ETA: 4.0
> ai. 僔僗僥儉僷僢働乕僕
>   偄偔偮偐偺棳媀偵傛傝僔僗僥儉僷僢

壗傜偐偺傗傝曽偱僔僗僥儉乣

> 働乕僕傪僒億乕僩偡傞昁梫偑偁傝傑偡丅偙傟偼丄彮側偔偲傕傑偲傕側僶僀僫儕 
> 娔嵏偍傛傃僶僀僫儕宍幃偺僷僢僠傪壜擻偵偟傑偡丅
>   愑擟幰: apb
>   ETA: 4.0
>
> aj. Provide support for binary packages in install
>   We should have an integrated install that can install a desktop as
>   functional as other free operating systems.  Without sacrificing
>   the quick and clean basic installs that we have now.  An extension
>   of sysinst might fit the bill.  Or a tool that's both invoked by
>   sysinst and available on a running system, e.g. pkgsrc-wip/ 
> pkg_select.
>   Responsible: agc and others
>   ETA: 4.0
> aj. 僀儞僗僩乕儖帪偵偍偗傞僶僀僫儕僷僢働乕僕偺採嫙
>   恦懍偱旤偟偄婛懚偺婎杮揑側僀儞僗僩乕儖娐嫬傪媇惖偵偣偢偵丄懠偺僼儕乕 
> 偺僆儁儗乕僥傿儞僌僔僗僥儉偲摨偠偔傜偄婡擻揑側僨僗僋僩僢僾傪僀儞僗僩乕 
> 儖偱偒傞摑崌僀儞僗僩乕儖偑偁傞傋偒偱偡丅sysinst
> 偺奼挘偼偙偺梫朷傪枮偨偡偐傕偟傟傑偣傫丅傑偨偼 sysinst 偵傛偭偰屇傃弌偝 
> 傟傞僣乕儖傗丄幚峴拞偺僔僗僥儉偱棙梡壜擻側僣乕儖偱偡乮椺偊偽
> pkgsrc-wip/pkg_select乯丅
>   愑擟幰: agc 懠
>   ETA: 4.0
>
> ak. Native signing/privacy software
>   This could be BPG (from SoC) or openpgp-sdk.
>   Responsible: agc, cjs and others
>   ETA: 4.0?
> ak. 僱僀僥傿僽偺彁柤/旈摻惈僜僼僩僂僃傾
>   偙傟偼 BPG(SoC 偐傜偺) 傑偨偼 openpgp-sdk 偐傕偟傟傑偣傫丅
>   愑擟幰: agc丄cjs丄懠
>   ETA: 4.0?
>
> al. Userland version identification
>   What binaries are installed?  Who really knows?  This relates at
>   least somewhat to (ai).
>   Responsible: TBD
>   ETA: ?
> al. 儐乕僓乕儔儞僪僶乕僕儑儞幆暿
>   偳傫側僶僀僫儕偑僀儞僗僩乕儖偝傟偰偄傑偡偐丠偩傟偑杮摉偵抦偭偰偄傑偡 
> 偐丠 彮側偔偲傕偙傟偼 ai. 偵偄偔傜偐娭楢偟傑偡丅
>   愑擟幰: TBD
>   ETA: ?
>
> 3. Platform dependent kernel
> 3. 僾儔僢僩僼僅乕儉偵埶懚偡傞僇乕僱儖
> ============================
> aa. Move evb ports to evb* if they're not already there (sandpoint)
>   The existing evb* ports are kind of catch-all ports for eval boards.
>   Some of the existing non-evb* ports really belong in the evb*  
> category.
>   Responsible: TBD
>   ETA: ?
>
> aa. evb 億乕僩偑偡偱偵 sandpoint 億乕僩偵柍偄側傜偽丄evb 億乕僩 傪  
> evb* 偺曽傊摦偐偟偰偔偩偝偄(sandpoint)
>   婛懚偺 evb* 億乕僩偼丄偳傫側庬椶偺昡壙儃乕僪偵傕懳墳偟傑偡丅婛懚偺 
> 旕 evb* 億乕僩偺偄偔偮偐偼丄杮摉偼 evb* 僇僥僑儕乕偵擖傝傑偡丅
>   愑擟幰: TBD
>   ETA: ?
>
> ab. m68k ports need to share more code
>   Some progress has been made here in recent years, but there is more
>   work to be done.
>   Responsible: TBD
>   ETA: ?
> ab. m68k 億乕僩偼丄傛傝懡偔偺僐乕僪傪嫟桳偡傞昁梫偑偁傝傑偡
>   嬤擭偄偔偮偐偺恑曕偑尒傜傟傑偟偨偑丄傑偩傑偩傗傞傋偒巇帠偑偁傝傑偡丅
>   愑擟幰: TBD
>   ETA: ?
>
> ac. Kernel core dump support for all platforms
>   Some platforms (PowerPC ports, ARM ports, etc.) don't have full
>   support for kernel core dumps and post-mortem debugging through
>   libkvm.  This should be updated.
>   Responsible: TBD
>   ETA: ?
> ac. 偡傋偰偺僾儔僢僩僼僅乕儉偺僇乕僱儖僐傾僟儞僾僒億乕僩
>   偄偔偮偐偺僾儔僢僩僼僅乕儉 (PowerPC 億乕僩丄ARM 億乕僩側偳) 偼丄僇乕 
> 僱儖僐傾僟儞僾傗 libkvm
> 傪巊偭偨専巰僨僶僢僌傪姰慡偵偼僒億乕僩偟偰偄傑偣傫丅偙傟傪傾僢僾僨乕僩 
> 偡傋偒偱偡丅
>   愑擟幰: TBD
>   ETA: ?
>
> ad. NDIS
>   Support for binary network drivers on x86 platforms.
>   Responsible: rittera
>   ETA: 4.0
> ad. NDIS
>   x86 僾儔僢僩僼僅乕儉忋偺僶僀僫儕乕僱僢僩儚乕僋僪儔僀僶乕偺僒億乕僩
>   愑擟幰: rittera
>   ETA: 4.0
>
> 4. Platform dependent userland
> 4. 僾儔僢僩僼僅乕儉偵埶懚偡傞儐乕僓乕儔儞僪
> ==============================
> ab. m68k should be able to share sets
>   Some progress has been made here in recent years, but there is more
>   work to be done.
>   Responsible: TBD
>   ETA: ?
> ab. m68k 偼 sets 傪嫟桳偱偒傞偼偢偱偡
>   嬤擭偄偔偮偐偺恑曕偑尒傜傟傑偟偨偑丄傑偩傑偩傗傞傋偒巇帠偑偁傝傑偡丅
>   愑擟幰: TBD
>   aETA: ?
>
>
> 5. Other
> 5. 偦偺懠
> ========
> aa. More and better regression tests
>   The suite of tests that we have now is limited.  We should expand
>   these and provide systems (or manage a volunteer pool?) to run the
>   tests on -current and release branches on a variety of platforms.
>   We also need to migrate all the tests that currently live in
>   'regress' to 'tests' so that they can make use of ATF.
>   ( Need to virtualize some with qemu or similar? )
>   Responsible: jmmv
>   ETA: 5.0 should have most of regress converted
>
> aa. 傛傝懡偔偺傛傝椙偄夞婣僥僗僩
>   尰嵼偁傞僥僗僩僗僀乕僩偼尷傜傟偰偄傑偡丅偝傑偞傑側僾儔僢僩僼僅乕儉 
> 偺 current 偲
> 儕儕乕僗僽儔儞僠梡偺僥僗僩傪塣梡偡傞偨傔偵丄僔僗僥儉傪採嫙偡傋偒偱偡  
> (傑偨偼儃儔儞僥傿傾僾乕儖傪娗棟偡傞? )丅傑偨丄ATF
> 傪棙梡偱偒傞傛偆偵偡傞偨傔偵尰嵼偺 'regress' 偐傜 'tests'
> 偺娐嫬偺偡傋偰傪僥僗僩偱偒傞傛偆偵偡傞昁梫偑偁傝傑偡丅(qemu 偐摨條偺暔 
> 傪壖憐壔偡傞偨傔偵傕昁梫偐? )
>   愑擟幰: jmmv
>   ETA: 5.0 偱偼丄戝晹暘偺夞婣僥僗僩傪曄峏偟側偗傟偽側傝傑偣傫丅
>
> ab. Native Java on multiple platforms
>   Getting i386, amd64, sparc64, and PowerPC would be a good start,
>   although PowerPC will require more work.  We have the go-ahead,
>   but we need the people to work on it.
>   Responsible: the Java porting crew
>   ETA: ?
>
> ab. 暋悢僾儔僢僩僼僅乕儉偺僱僀僥傿僽 Java
>   i386丄amd64丄sparc64丄PowerPC 傪擖庤偡傟偽岲挷偵僗僞乕僩偱偒傞偱偟傚 
> 偆丅PowerPC
> 偼丄傛傝懡偔偺巇帠傪昁梫偲偡傞偱偟傚偆偗傟偳丅僗僞乕僩偱偒傑偡偑丄棙梡 
> 幰偑偙傟偵庢傝慻傓昁梫偑偁傝傑偡丅
>   愑擟幰: Java 堏怉嶌嬈堳
>   ETA: ?
>
> ac. Power control framework
>   Related to suspend/resume support, we should have some framework
>   for dynamically stepping processor speed, controlling fans, shutting
>   down and/or powering subsystems to conserve power and keep the  
> system
>   with thermal limits.
>   Responsible: TBD
>   ETA: ?
> ac. 揹尮惂屼憰抲僼儗乕儉儚乕僋
>   僒僗儁儞僪/儕僕儏乕儉偵娭楢偟偰丄僾儘僙僢僒乕偺摦揑僗僥僢僾僗僺乕僪丄 
> 僼傽儞惂屼丄僔儍僢僩僟僂儞傗徣揹椡偺偨傔偺揹尮僒僽僔僗僥儉丄擬惂尷抣巊 
> 梡偵傛傞僔僗僥儉堐帩丄偲偄偆偄偔偮偐偺僼儗乕儉儚乕僋偑偁傝傑偡丅
>   愑擟幰: TBD
>   ETA: ?
>
> <<<<偙偙傑偱
Follow-Ups:
- Re: /about/ROADMAP
  - From: 话呜扛( Miwa Susumu )<miwarin@gmail.com>
Prev by Date: CVS commit: htdocs
Next by Date: CVS commit: htdocs
Prev by thread: SA2009-001 ~ 013
Next by thread: Re: /about/ROADMAP
Index(es):
- Date
- Thread