Recent changes to this wiki:

--- /dev/null	2015-02-27 17:50:00.000000000 +0000
+++ wikisrc/ports/evbarm/odroid-c1.mdwn	2015-02-27 17:58:37.000000000 +0000
@@ -0,0 +1,18 @@
+[[!meta title="NetBSD/evbarm on Hardkernel ODROID-C1"]]
+
+[[!toc levels=2]]
+
+# ODROID-C1 UART pins
+
+From [ODROID Forum](http://forum.odroid.com/viewtopic.php?f=115&t=7684):
+
+[[!template  id=programlisting text="""
+ ___UART____
+|Pin 4 - GND|
+|Pin 3 - RXD|
+|Pin 2 - TXD|
+|Pin 1 - VCC|
+\___________|
+
+3.3V LVTTL
+"""]]

--- /dev/null	2015-02-23 10:20:00.000000000 +0000
+++ wikisrc/summits/AsiaBSDCon_2015_NetBSD_Summit.mdwn	2015-02-23 10:21:11.000000000 +0000
@@ -0,0 +1,21 @@
+## Details
+
+The NetBSD developer summit at AsiaBSDCon 2015 will be held Friday,
+March 13th.
+
+## Planning to attend?
+
+[[!table data="""
+First Last | `login@` | comment(s)
+Masanobu SAITOH | `msaitoh` | 
+"""]]
+
+## Planning to present something?
+
+[[!table data="""
+Speaker  |Title
+`login@` |_Very Interesting Thing_
+"""]]
+
+## Discussions
+*

removed
--- wikisrc/projects/project/netbsd_on_microsoft_azure/comment_2_e5e7c434226f63fb28608330dbd22661._comment	2015-02-22 04:10:29.000000000 +0000
+++ /dev/null	2015-02-22 04:10:03.000000000 +0000
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawno_FsM7bUgCzS526w5T3_CFxZ-413P3wY"
- nickname="Ross"
- subject="A few of useful resources.."
- date="2015-02-22T04:08:50Z"
- content="""
-Instructions on how to build a FreeBSD image: http://azure.microsoft.com/blog/2014/05/22/running-freebsd-in-azure/
-
-Instructions on how to build a Linux image: http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-tutorial/
-
-Images can be published on http://vmdepot.msopentech.com when complete
-
-How to customize and republish an image once a base image is available in VM Depot: https://vmdepot.msopentech.com/tutorial/freeBSD.html
-"""]]

Added a comment: A few of useful resources..
--- /dev/null	2015-02-22 04:10:03.000000000 +0000
+++ wikisrc/projects/project/netbsd_on_microsoft_azure/comment_2_e5e7c434226f63fb28608330dbd22661._comment	2015-02-22 04:10:08.000000000 +0000
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawno_FsM7bUgCzS526w5T3_CFxZ-413P3wY"
+ nickname="Ross"
+ subject="A few of useful resources.."
+ date="2015-02-22T04:08:50Z"
+ content="""
+Instructions on how to build a FreeBSD image: http://azure.microsoft.com/blog/2014/05/22/running-freebsd-in-azure/
+
+Instructions on how to build a Linux image: http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-tutorial/
+
+Images can be published on http://vmdepot.msopentech.com when complete
+
+How to customize and republish an image once a base image is available in VM Depot: https://vmdepot.msopentech.com/tutorial/freeBSD.html
+"""]]

Added a comment: A few of useful resources..
--- /dev/null	2015-02-22 04:00:01.000000000 +0000
+++ wikisrc/projects/project/netbsd_on_microsoft_azure/comment_1_6b35e01eee06c30c14dd5f4e79a50852._comment	2015-02-22 04:08:30.000000000 +0000
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawno_FsM7bUgCzS526w5T3_CFxZ-413P3wY"
+ nickname="Ross"
+ subject="A few of useful resources.."
+ date="2015-02-22T04:07:10Z"
+ content="""
+Instructions on how to build a FreeBSD image: http://azure.microsoft.com/blog/2014/05/22/running-freebsd-in-azure/
+
+Instructions on how to build a Linux image: http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-tutorial/
+
+Images can be published on http://vmdepot.msopentech.com when complete
+
+How to customize and republish an image once a base image is available in VM Depot: https://vmdepot.msopentech.com/tutorial/freeBSD.html
+"""]]

Index: wikisrc/projects/project/secureplt.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/secureplt.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/secureplt.mdwn	20 Feb 2015 19:21:44 -0000	1.3
+++ wikisrc/projects/project/secureplt.mdwn	20 Feb 2015 20:41:05 -0000	1.4
@@ -1,6 +1,6 @@
 [[!template id=project
 
-title="Secure-PLT - supporting new PLT formats on alpha"
+title="Secure-PLT - supporting RELRO binaries"
 
 contact="""
 [tech-userlevel](mailto:tech-userlevel@NetBSD.org)
@@ -15,15 +15,19 @@
 duration="3 months"
 
 description="""
-Currently kernels with options PAX_MPROTECT can not execute dynamically linked binaries on most RISC architectures, because the PLT format defined by the ABI of these architectures uses self-modifying code.
+All architectures suffer from code injection issues because the only writable segment is the PLT/GOT. RELRO (RELocation Read Only) is a mitigation technique that is used during dynamic linking to prevent access to the PLT/GOT. There is partial RELRO which protects that GOT but leaves the PLT writable, and full RELRO that protects both at the expense of performing a full symbol resolution at startup time. The project is about making the necessary modifications to the dynamic loader (ld_elf.so) to make RELRO work.
+
+If that is completed, then we can also add the following improvement:
+Currently kernels with options PAX_MPROTECT can not execute dynamically linked binaries on most RISC architectures, because the PLT format defined by the ABI of these architectures uses self-modifying code. New binutils versions have introduced a different PLT format (enabled with --secureplt) for alpha and powerpc.
+
 
-New binutils versions have introduced a different PLT format (enabled with --secureplt) for alpha and powerpc.
 
 Milestones:
 
-* This project (for alpha) is to add support for the new PLT formats introduced in binutils 2.17 and gcc4.1 This will require changes to the dynamic loader (ld.elf_so), various assembly headers, and library files.
-* Support for both the old and new formats in the same invocation will be required.
 * For all architectures we can improve security by implementing [relro](http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html).
+* Once this is done, we can improve security for the RISC architectures by adding support for the new PLT formats introduced in binutils 2.17 and gcc4.1 This will require changes to the dynamic loader (ld.elf_so), various assembly headers, and library files.
+* Support for both the old and new formats in the same invocation will be required.
+
 """
 ]]
 

Index: wikisrc/projects/project/verify_netbsd32.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/verify_netbsd32.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/verify_netbsd32.mdwn	20 Feb 2015 19:21:44 -0000	1.3
+++ wikisrc/projects/project/verify_netbsd32.mdwn	20 Feb 2015 19:48:08 -0000	1.4
@@ -27,6 +27,7 @@
 This and the resulting padding introduced by the compiler can create hard to find bugs.
 
 goals/milestones:
+
 * replace the manual labour with an automatic tool
 > > This tool should allow both verification / generation of structure definitions for use in netbsd32 code 
 > > allow generation of system call stubs and conversion functions.

Index: wikisrc/projects/project/launchd-port.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/launchd-port.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/launchd-port.mdwn	20 Feb 2015 17:12:46 -0000	1.3
+++ wikisrc/projects/project/launchd-port.mdwn	20 Feb 2015 19:46:57 -0000	1.4
@@ -35,6 +35,8 @@
 
 """
 
+(noted by edreyfus) A lot of mach functionality were added in COMPAT_MACH (src/sys/compat/mach), which has been removed from cvs, but it could be resurrected. 
+
 ]]
 
 [[!tag gsoc]]

removed
--- wikisrc/projects/project/launchd-port/comment_1_602ba74efd23ef50aa56bce1ebf7b189._comment	2015-02-20 19:45:49.000000000 +0000
+++ /dev/null	2015-02-20 19:40:01.000000000 +0000
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://openid.espci.fr/edreyfus"
- ip="213.41.141.172"
- subject="Mach feature"
- date="2012-11-07T02:18:04Z"
- content="""
-A lot of mach functionality were added in COMPAT_MACH (src/sys/compat/mach), which has been removed from cvs, but it could be resurrected.
-"""]]

Index: wikisrc/projects/project/libintl.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/libintl.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/libintl.mdwn	20 Feb 2015 17:12:46 -0000	1.3
+++ wikisrc/projects/project/libintl.mdwn	20 Feb 2015 19:44:31 -0000	1.4
@@ -23,6 +23,7 @@
 * Implement support for the extensions in the message catalog format. libintl should be able to process all .mo files from current gettext and return the same results via the API.
 * Provide a clean implementation of msgfmt.
 * Other components of gettext like msgmerge and the gettext frontend should be evaluated case-by-case if they are useful for the base system and whether third party software in pkgsrc depends on them.
+* demonstrate the elimination of GNU gettext dependencies
 
 """
 ]]

Index: wikisrc/projects/project/inetd-enhancements.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/inetd-enhancements.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/projects/project/inetd-enhancements.mdwn	20 Feb 2015 16:42:42 -0000	1.5
+++ wikisrc/projects/project/inetd-enhancements.mdwn	20 Feb 2015 19:43:39 -0000	1.6
@@ -15,7 +15,7 @@
 duration="3 months"
 
 description="""
-Enhance inetd in NetBSD
+inetd is a classic method for launching network programs on-the-fly and some of its ideas are coming back into vogue.  Enhancing this daemon should include investigations into other similar systems in other operating systems.
 
 Primary milestones:
 

Index: wikisrc/projects/project/isdn-nt-asterisk.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/isdn-nt-asterisk.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/isdn-nt-asterisk.mdwn	20 Feb 2015 16:42:42 -0000	1.3
+++ wikisrc/projects/project/isdn-nt-asterisk.mdwn	20 Feb 2015 19:40:28 -0000	1.4
@@ -15,6 +15,9 @@
 duration="3 months"
 
 description="""
+NetBSD is a common target for asterisk installations and could use some improvements.
+Improving ISDN puts us back in the running as a high-end installation target.
+
 This project has three milestones:
 
 * add support for the NT (network) side of ISDN to the NetBSD ISDN stack
@@ -22,6 +25,9 @@
 * show this makes it easier to test new ISDN card drivers
 
 Previous work in this area can be found at the [alternative ISDN driver site](http://www.turbocat.net/~hselasky/isdn4bsd/).
+
+The student needs access to ISDN and telephony hardware for this project.
+
 """
 ]]
 

Index: wikisrc/projects/project/common-boot-cfg.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/common-boot-cfg.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/common-boot-cfg.mdwn	20 Feb 2015 16:42:42 -0000	1.3
+++ wikisrc/projects/project/common-boot-cfg.mdwn	20 Feb 2015 19:38:28 -0000	1.4
@@ -21,6 +21,7 @@
 and the situation needs to be improved.
 
 The milestones of this project:
+
 * split the machine dependent parts out
 * provide generic, machine independent support for most of the /boot.cfg handling
 * leave configuration (like what commands are allowed) to the architecture specific code

remove gsoc tag since it was already worked in a previous year
Index: wikisrc/projects/project/virtual-box-guest-tools.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/virtual-box-guest-tools.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/projects/project/virtual-box-guest-tools.mdwn	19 Feb 2014 07:16:49 -0000	1.7
+++ wikisrc/projects/project/virtual-box-guest-tools.mdwn	20 Feb 2015 19:32:00 -0000	1.8
@@ -47,6 +47,3 @@
 """
 
 ]]
-
-
-[[!tag gsoc]]

add 'milestones' to a bunch of pojects, take 4
Index: wikisrc/projects/project/raidframe-raid6.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/raidframe-raid6.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/raidframe-raid6.mdwn	18 Feb 2015 22:51:55 -0000	1.2
+++ wikisrc/projects/project/raidframe-raid6.mdwn	20 Feb 2015 19:21:44 -0000	1.3
@@ -12,10 +12,26 @@
 
 category="filesystems"
 difficulty="medium"
-duration="unknown"
+duration="two months"
 
 description="""
 Test and debug the RAID 6 implementation in RAIDframe.
+
+NetBSD uses RAIDframe (raid(4)) and stub code exists for RAID6 but is not very
+documented or well tested.  Obviously, this code needs to be researched and
+vetted by an interested party.  Other BSD projects should be consulted freely.
+
+Milestones:
+* setup a working RAID 6 using RAIDFrame
+* document RAID6 in raid(4) manual page
+* port/develop a set of reliability and performance tests
+* fix bugs along the way
+* automate RAID testing in atf
+
+Bonus:
+* Document how to add new RAID levels to RAIDframe
+* (you're awesome bonus) add RAID 1+0, etc
+
 """
 ]]
 
Index: wikisrc/projects/project/rewrite-pkg_comp.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/rewrite-pkg_comp.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/rewrite-pkg_comp.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/rewrite-pkg_comp.mdwn	20 Feb 2015 19:21:44 -0000	1.3
@@ -23,7 +23,7 @@
 
 The language of choice for the reimplementation will be Python. The code will be hosted outside of pkgsrc to be able to distribute it as a standalone tool.
 
-The following items should be accomplished:
+The following milestones should be accomplished:
 
 * Implement a "sandbox" library with an interface to programmatically create and manage a sandboxed file system. The structure of the sandbox has to be configurable through a template, and templates have to be provided for a few systems. The sandbox itself will be constructed either by unpacking tarballs with the system contents (such as the NetBSD distfiles), by null-mounting directories of the host file system, or both.
 * Implement a command-line frontend utility for the "sandbox" library. This tool is completely unaware of pkgsrc but will be really nice to have (and trivial to write, as all the juicy bits are in the library). Will be useful as part of server administration, as it will allow isolating services in a fairly easy manner.
Index: wikisrc/projects/project/secureplt.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/secureplt.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/secureplt.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/secureplt.mdwn	20 Feb 2015 19:21:44 -0000	1.3
@@ -19,11 +19,11 @@
 
 New binutils versions have introduced a different PLT format (enabled with --secureplt) for alpha and powerpc.
 
-This project (for alpha) is to add support for the new PLT formats introduced in binutils 2.17 and gcc4.1 This will require changes to the dynamic loader (ld.elf_so), various assembly headers, and library files.
+Milestones:
 
-Support for both the old and new formats in the same invocation will be required.
-
-For all architectures we can improve security by implementing [relro](http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html).
+* This project (for alpha) is to add support for the new PLT formats introduced in binutils 2.17 and gcc4.1 This will require changes to the dynamic loader (ld.elf_so), various assembly headers, and library files.
+* Support for both the old and new formats in the same invocation will be required.
+* For all architectures we can improve security by implementing [relro](http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html).
 """
 ]]
 
Index: wikisrc/projects/project/sysinst-xinterface.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/sysinst-xinterface.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/sysinst-xinterface.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/sysinst-xinterface.mdwn	20 Feb 2015 19:21:44 -0000	1.3
@@ -29,6 +29,12 @@
 
 An optional extension of the project is to modify the creation of one or more port's install CD to make use of the new xsysinst.
 
+Milestones include:
+* modify the "menuc" tool to support X
+* keep text/serial console installing
+* demonstrate a GUI install
+* demonstrate fallback to the text installer
+
 The candidate must have:
 
 * familiarity with the system installer. You should have used sysinst to install the system.
Index: wikisrc/projects/project/sysinst_pkgs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/sysinst_pkgs.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/sysinst_pkgs.mdwn	14 Feb 2013 22:36:08 -0000	1.3
+++ wikisrc/projects/project/sysinst_pkgs.mdwn	20 Feb 2015 19:21:44 -0000	1.4
@@ -20,7 +20,7 @@
 The packages might be simple packages like screen or bigger ones like firefox.
 Configuration of the packages is not required to happen in sysinst.
 
-A short overview of the steps involved:
+A short overview of the milestones involved:
 
 * Improve sysinst so it can list a pkgsummary.gz file on the install media and offer to install a subset of them. There should be a chooser included in sysinst where the user can select the packages they want to install.
 
Index: wikisrc/projects/project/verify_netbsd32.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/verify_netbsd32.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/verify_netbsd32.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/verify_netbsd32.mdwn	20 Feb 2015 19:21:44 -0000	1.3
@@ -26,10 +26,13 @@
 On i386 uint64_t has a 32bit alignment, but on AMD64 it uses natural (64bit) alignment.
 This and the resulting padding introduced by the compiler can create hard to find bugs.
 
-The goal of this project is to replace the manual labour with an automatic tool.
-This tool should allow both verification / generation of structure definitions for use in netbsd32 code as well as allow generation of system call stubs and conversion functions.
+goals/milestones:
+* replace the manual labour with an automatic tool
+> > This tool should allow both verification / generation of structure definitions for use in netbsd32 code 
+> > allow generation of system call stubs and conversion functions.
+> > Generated stubs should also ensure that no kernel stack data is leaked in hidden padding without having to resort to unnecessary large memset calls.
+
 For this purpose, the [Clang C parser](http://clang.llvm.org) or the [libclang frontend](http://llvm.org/devmtg/2010-11/Gregor-libclang.pdf) can be used to analyse the C code.
-Generated stubs should also ensure that no kernel stack data is leaked in hidden padding without having to resort to unnecessary large memset calls.
 """
 ]]
 

add 'milestones' to a bunch of pojects, take 3
Index: wikisrc/projects/project/netbsd_on_microsoft_azure.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/netbsd_on_microsoft_azure.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/projects/project/netbsd_on_microsoft_azure.mdwn	18 Mar 2013 12:23:38 -0000	1.5
+++ wikisrc/projects/project/netbsd_on_microsoft_azure.mdwn	20 Feb 2015 17:42:22 -0000	1.6
@@ -3,10 +3,11 @@
 title="NetBSD/azure -- Bringing NetBSD to Microsoft Azure"
 
 contact="""
-[port-xen](mailto:port-xen@NetBSD.org) ???
+[port-xen](mailto:port-xen@NetBSD.org)
 """
 
 mentors="""
+[Christos Zoulas](mailto:christos@NetBSD.org)
 """
 
 category="kernel"
@@ -24,6 +25,11 @@
 
 [FreeBSD drivers for the Hyper-V virtual machine interface](http://freebsdonhyper-v.github.com/)
 
+Milestones for this project:
+
+* booting NetBSD on azure
+* process for automatically building azure-friendly images, similar to amazon AMI
+
 """
 
 ]]
Index: wikisrc/projects/project/opencrypto_swcrypto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/opencrypto_swcrypto.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/opencrypto_swcrypto.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/opencrypto_swcrypto.mdwn	20 Feb 2015 17:42:22 -0000	1.3
@@ -15,7 +15,17 @@
 duration="3 months"
 
 description="""
-Use multiple cores efficiently (that already works reasonably well for multiple request streams); actually use faster versions of complex transforms (CBC, counter modes) from our in-tree OpenSSL or elsewhere (eg libtomcrypt); add support for asymmetric operations (public key). Tie public-key operations into veriexec somehow for extra credit (probably a very good start towards an undergrad thesis project).
+swcrypto could use a variety of enhanacements
+
+Milestones/deliverables:
+
+* use multiple cores efficiently (that already works reasonably well for multiple request streams)
+* use faster versions of complex transforms (CBC, counter modes) from our in-tree OpenSSL or elsewhere (eg libtomcrypt)
+* add support for asymmetric operations (public key)
+
+Extra credit:
+
+* Tie public-key operations into veriexec somehow for extra credit (probably a very good start towards an undergrad thesis project).
 """
 ]]
 
Index: wikisrc/projects/project/pkgsrc_binpkg_depends.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/pkgsrc_binpkg_depends.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/pkgsrc_binpkg_depends.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/pkgsrc_binpkg_depends.mdwn	20 Feb 2015 17:42:22 -0000	1.3
@@ -31,6 +31,12 @@
 It would be good to provide scripts that convert from the current state to the new one, and test it with a bulk build.
 
 Of course it's not expected that all packages be converted to the new framework in the course of this project, but the further steps should be made clear.
+
+goals/milestones:
+* invent a replacement for buildlink3.mk files, keeping current features
+* demonstrate your new tool as a buildlink3.mk replacement including new features
+* execute a bulk build with as many packages as possible using the new buildlink
+
 """
 ]]
 
Index: wikisrc/projects/project/pkgsrc_config_vcs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/pkgsrc_config_vcs.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/pkgsrc_config_vcs.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/pkgsrc_config_vcs.mdwn	20 Feb 2015 17:42:22 -0000	1.3
@@ -29,6 +29,15 @@
 * Regular automated check-ins of the entire live pkgsrc configuration should be easy to set up, but also manual check-ins of singular files so the local admin can use meaningful commit messages when they change their config, even if they are not experienced users of version control systems
 
 The actual commands to the version control system should be hidden behind an abstraction layer, and the vcs operations should be kept simple, so that other compatibility layers can be written, and eventually the user can pick their vcs of choice (and also a vcs location of choice, in case e.g. the enterprise configuration repository is on a central subversion server).
+
+milestones/goals:
+* choose a VCS system (BSD licensed is a nice-to-have)
+* write wrappers around it, or embed its functionality
+* demonstrate usage in upgrades
+
+bonus:
+* extend functionality into additional VCS systems
+
 """
 ]]
 
Index: wikisrc/projects/project/pkgsrc_installtasks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/pkgsrc_installtasks.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/pkgsrc_installtasks.mdwn	30 Jul 2013 19:43:46 -0000	1.3
+++ wikisrc/projects/project/pkgsrc_installtasks.mdwn	20 Feb 2015 17:42:22 -0000	1.4
@@ -17,7 +17,13 @@
 description="""
 Instead of including install scripts from the infrastructure into every binary package, just include the necessary information and split the scripts off into a separate package that is installed first (right after bootstrap, as soon as the first package needs it). This affects user creation, installation of tex packages, ...
 
-Also add support for actions that happen once after a big upgrade session, instead of once per package (e.g. ls-lR rebuild for tex).
+Milestones:
+
+* identify example packages installing users, groups, and documentation
+* demonstrate pkgsrc packages which add users, etc
+* Also add support for actions that happen once after a big upgrade session, instead of once per package (e.g. ls-lR rebuild for tex).
+* convert some existing packages to use this new framework
+* allow options framework to configure these resources per-package
 
 An intermediate step would be to replace various remaining INSTALL scripts by declarative statements and install script snippets using them.
 """
Index: wikisrc/projects/project/pkgsrc_precise_dependencies.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/pkgsrc_precise_dependencies.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/pkgsrc_precise_dependencies.mdwn	17 Mar 2012 21:53:08 -0000	1.1
+++ wikisrc/projects/project/pkgsrc_precise_dependencies.mdwn	20 Feb 2015 17:42:22 -0000	1.2
@@ -28,6 +28,12 @@
 actually used to build new package. Ideally, the tool should
 report files used during configure, build, and test stages,
 and packages these files are provided by.
+
+Milestones:
+* find or develop a good dependency graph algorithm
+* implement and demonstrate your new system in pkgsrc by adding a make target
+* expose this algorithm for use by websites such as pkgsrc.se
+
 """
 ]]
 
Index: wikisrc/projects/project/pkgsrc_spawn_support.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/pkgsrc_spawn_support.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/projects/project/pkgsrc_spawn_support.mdwn	21 Mar 2012 10:00:36 -0000	1.9
+++ wikisrc/projects/project/pkgsrc_spawn_support.mdwn	20 Feb 2015 17:42:22 -0000	1.10
@@ -36,9 +36,11 @@
 
 Optionally, MinGW spawn support can be added as well.
 
-The main goal of this project is to support starting processes and
-subprocesses by posix_spawn in devel/bmake and in shells/pdksh,
-measure its efficiency and compare it to traditional fork+exec.
+Milestones:
+
+* support starting processes and subprocesses by posix_spawn in devel/bmake
+* support starting processes and subprocesses by posix_spawn in shells/pdksh,
+* measure its efficiency and compare it to traditional fork+exec.
 """
 ]]
 

add 'milestones' to a bunch of pojects, take 2
Index: wikisrc/projects/project/launchd-port.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/launchd-port.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/launchd-port.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/launchd-port.mdwn	20 Feb 2015 17:12:46 -0000	1.3
@@ -16,7 +16,25 @@
 
 description="""
 [Launchd](http://en.wikipedia.org/wiki/Launchd) is a MacOS/X utility that is used to start and control daemons similar to init(8), but much more powerful. There was an effort to port launchd to FreeBSD, but it seems to be [abandoned](http://wiki.freebsd.org/launchd). We should first investigate what happened to the FreeBSD effort to avoid duplicating work. The port is not trivial because launchd uses a lot of mach features.
+
+Milestones:
+
+* report of FreeBSD efforts (past and present)
+* launchd port replacing: init
+* launchd port replacing: rc
+* launchd port compatible with: rc.d scripts
+* launchd port replacing: watchdogd
+
+
+Nice to have:
+
+* launchd port replacing/integrating: inetd
+* launchd port replacing: atd
+* launchd port replacing: crond
+* launchd port replacing: (the rest)
+
 """
+
 ]]
 
 [[!tag gsoc]]
Index: wikisrc/projects/project/ledapi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/ledapi.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/ledapi.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/ledapi.mdwn	20 Feb 2015 17:12:46 -0000	1.3
@@ -18,6 +18,14 @@
 Design and implement a general API for control of LED and LCD type devices on NetBSD. The API would allow devices to register individual LED and LCD devices, along with a set of capabilities for each one. Devices that wish to display status via an LED/LCD would also register themselves as an event provider. A userland program would control the wiring of each event provider, to each output indicator. The API would need to encompass all types of LCD displays, such as 3 segment LCDs, 7 segment alphanumerics, and simple on/off state LED's. A simple example is a keyboard LED, which is an output indicator, and the caps-lock key being pressed, which is an event provider.
 
 There is prior art in OpenBSD; it should be checked for suitability, and any resulting API should not differ from theirs without reason.
+
+Milestones:
+
+* a port of OpenBSD's LED tools
+* a userland tool to control LED
+* demonstration of functionality
+* integration into NetBSD
+
 """
 ]]
 
Index: wikisrc/projects/project/libcurses-automated-test.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/libcurses-automated-test.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/libcurses-automated-test.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/libcurses-automated-test.mdwn	20 Feb 2015 17:12:46 -0000	1.3
@@ -17,9 +17,14 @@
 description="""
 The curses library is an important part of the NetBSD operating system, many applications rely on the correct functioning of the library. Performing modifications on the curses library can be difficult because the effects of the change may be subtle and can introduce bugs that are not detected for a long time.
 
-The aim of this project is to produce a suite of high quality tests for the curses library.  These tests should exercise every aspect of the library functionality.
+The testing framework has been written to run under the atf framework but has not been committed to the tree yet.
 
-The testing framework has been written to run under the atf framework but has not been committed to the tree yet.  The student undertaking this project will be provided with the testing framework and will use this to generate test cases for curses library calls.  Most of the work will require analytical skills to verify the output of the test is actually correct before encapsulating that output into a validation file.
+The student undertaking this project will be provided with the testing framework and will use this to generate test cases for curses library calls.  Most of the work will require analytical skills to verify the output of the test is actually correct before encapsulating that output into a validation file.
+
+Milestones for this project:
+
+* produce a suite of high quality tests for the curses library
+* These tests should exercise every aspect of the library functionality.
 
 This project will need a good understanding of the curses library and will provide the student with a much deeper understanding of the operation of curses.
 """
Index: wikisrc/projects/project/libintl.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/libintl.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/libintl.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/libintl.mdwn	20 Feb 2015 17:12:46 -0000	1.3
@@ -17,7 +17,7 @@
 description="""
 NetBSD provides a BSD licensed implementation of libintl. This implementation is based on the specifications from GNU gettext. It has not kept up with the development of gettext in the last few years though, lacking e.g. support for context specific translations. NetBSD currently also has to depend on GNU gettext to recreate the message catalogs.
 
-Goals for this project include:
+Milestones for this project include:
 
 * Restore full API compatibility with current gettext. At the time of writing, this is gettext 0.18.1.1.
 * Implement support for the extensions in the message catalog format. libintl should be able to process all .mo files from current gettext and return the same results via the API.
Index: wikisrc/projects/project/live-upgrade.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/live-upgrade.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/projects/project/live-upgrade.mdwn	14 Apr 2013 11:48:58 -0000	1.4
+++ wikisrc/projects/project/live-upgrade.mdwn	20 Feb 2015 17:12:46 -0000	1.5
@@ -15,7 +15,9 @@
 duration="3 months"
 
 description="""
-Updating an operating system image can be fraught with danger, an error could cause the system to be unbootable and require significant work to restore the system to operation.  The aim of this project is to permit a system to be updated while it is running only requiring a reboot to activate the updated system and provide the facility to rollback to a "known good" system in the event that the update causes regressions.  The project should do the following:
+Updating an operating system image can be fraught with danger, an error could cause the system to be unbootable and require significant work to restore the system to operation.  The aim of this project is to permit a system to be updated while it is running only requiring a reboot to activate the updated system and provide the facility to rollback to a "known good" system in the event that the update causes regressions.
+
+Milestones for this project:
 
 * Make a copy of the currently running system
 * Either apply patches, install binary sets, run a source build with the copy as the install target

add 'milestones' to a bunch of pojects, take 1
Index: wikisrc/projects/project/binary_compat_puffs_backend.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/binary_compat_puffs_backend.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/binary_compat_puffs_backend.mdwn	27 Feb 2014 04:52:33 -0000	1.3
+++ wikisrc/projects/project/binary_compat_puffs_backend.mdwn	20 Feb 2015 16:42:42 -0000	1.4
@@ -17,7 +17,7 @@
 description="""
 Currently, the [puffs(3)](http://netbsd.gw.com/cgi-bin/man-cgi?puffs+3+NetBSD-5.1+i386) interface between the kernel and userspace uses various system structures for passing information. Examples are `struct stat` and `struct uucred`. If these change in layout (such as with the time_t size change in NetBSD 6.0), old puffs servers must be recompiled.
 
-The purpose of the project is to:
+The project milestones are:
 
 * *define* a binary-independent protocol
 * *implement* support
Index: wikisrc/projects/project/common-boot-cfg.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/common-boot-cfg.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/common-boot-cfg.mdwn	27 Feb 2014 07:00:44 -0000	1.2
+++ wikisrc/projects/project/common-boot-cfg.mdwn	20 Feb 2015 16:42:42 -0000	1.3
@@ -20,9 +20,11 @@
 However, they do not share code, nor even the basic command parser. Obviously this is not the NetBSD way to do things
 and the situation needs to be improved.
 
-The goal of this project is to split the machine dependent parts out and provide generic, machine independent support
-for most of the /boot.cfg handling, leaving configuration (like what commands are allowed) to the architecture specific
-code, as well as provide means for overriding command handlers (i.e. implement a common command differently).
+The milestones of this project:
+* split the machine dependent parts out
+* provide generic, machine independent support for most of the /boot.cfg handling
+* leave configuration (like what commands are allowed) to the architecture specific code
+* provide means for overriding command handlers (i.e. implement a common command differently)
 
 Due to the organization of the bootstrapping code this is not as easy as it sounds at first sight, but it does not require
 deep kernel hacking skills either. Having various hardware available for testing is a bonus, but not required.
Index: wikisrc/projects/project/disk-removal.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/disk-removal.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/disk-removal.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/disk-removal.mdwn	20 Feb 2015 16:42:42 -0000	1.3
@@ -15,7 +15,15 @@
 duration="3 months"
 
 description="""
-Make NetBSD behave gracefully when a "live" USB/FireWire disk drive is accidentally detached and re-attached by, for example, creating a virtual block device that receives block-read/write commands on behalf of the underlying disk driver. This device will delegate reads and writes to the disk driver, but it will keep a list of commands that are "outstanding," that is, reads that the disk driver has not completed, and writes that have not "hit the platter," so to speak. Following disk re-attachment, the virtual block device replays its list of outstanding commands. A correct solution will not replay commands to the wrong disk if the removable was replaced instead of re-attached. Provide a character device for userland to read indications that a disk in use was abruptly detached.
+Make NetBSD behave gracefully when a "live" USB/FireWire disk drive is accidentally detached and re-attached by, for example, creating a virtual block device that receives block-read/write commands on behalf of the underlying disk driver.
+
+This device will delegate reads and writes to the disk driver, but it will keep a list of commands that are "outstanding," that is, reads that the disk driver has not completed, and writes that have not "hit the platter," so to speak.
+
+
+Milestones:
+
+* Provide a character device for userland to read indications that a disk in use was abruptly detached.
+* Following disk re-attachment, the virtual block device replays its list of outstanding commands. A correct solution will not replay commands to the wrong disk if the removable was replaced instead of re-attached.
 
 Open questions: Prior art? Isn't this how the Amiga worked? How will this interact with mount/unmount—is there a use-count on devices? Can you leverage "wedges" in your solution? Does any/most/all removable storage indicate reliably when a block written has actually reached the medium?
 """
Index: wikisrc/projects/project/fast-time.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/fast-time.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/fast-time.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/fast-time.mdwn	20 Feb 2015 16:42:42 -0000	1.3
@@ -15,7 +15,14 @@
 duration="3 months"
 
 description="""
-Design and implement a mechanism that allows for fast user level access to kernel time data structures for NetBSD. For certain types of small data structures the system call overhead is significant. This is especially true for frequently invoked system calls like [clock_gettime(2)](http://netbsd.gw.com/cgi-bin/man-cgi?clock_gettime+2+NetBSD-5.1+i386) and [gettimeofday(2)](http://netbsd.gw.com/cgi-bin/man-cgi?gettimeofday+2+NetBSD-5.1+i386). With the availability of user level readable high frequency counters it is possible to create fast implementations for precision time reading. Optimizing clock_gettime(2) and alike will reduce the strain from applications frequently calling these system calls and improves timing information quality for applications like NTP. The implementation would be based on a to be modified version of the timecounters implementation in NetBSD.
+Design and implement a mechanism that allows for fast user level access to kernel time data structures for NetBSD. For certain types of small data structures the system call overhead is significant. This is especially true for frequently invoked system calls like [clock_gettime(2)](http://netbsd.gw.com/cgi-bin/man-cgi?clock_gettime+2+NetBSD-5.1+i386) and [gettimeofday(2)](http://netbsd.gw.com/cgi-bin/man-cgi?gettimeofday+2+NetBSD-5.1+i386). With the availability of user level readable high frequency counters it is possible to create fast implementations for precision time reading. Optimizing clock_gettime(2) and alike will reduce the strain from applications frequently calling these system calls and improves timing information quality for applications like NTP. The implementation would be based on a to-be-modified version of the timecounters implementation in NetBSD.
+
+Milestones:
+
+* Produce optimizations for clock_gettime
+* Produce optimizations for gettimeofday
+* Show benchmarks before and after
+* start evolving timecounters in NetBSD, demonstrating your improvements
 
 See also the [Paper on Timecounters by Poul-Henning Kamp](http://phk.freebsd.dk/pubs/timecounter.pdf).
 """
Index: wikisrc/projects/project/fs-services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/fs-services.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/projects/project/fs-services.mdwn	27 Feb 2014 07:20:54 -0000	1.4
+++ wikisrc/projects/project/fs-services.mdwn	20 Feb 2015 16:42:42 -0000	1.5
@@ -19,7 +19,7 @@
 
 This project investigates the first steps in turning file systems into network-transparent services by making it possible to mount any kernel file system type from any location on the network. The file system components to be used are [puffs](http://www.netbsd.org/docs/puffs/) and [rump](http://www.netbsd.org/docs/puffs/rump.html). puffs is used to forward local file system requests from the kernel to userspace and rump is used to facilitate running the kernel file system in userspace as a service daemon.
 
-The subtasks are the following:
+The milestones are the following:
 
 * Write the necessary code to be able to forward requests from one source to another. This involves most likely reworking a bit of the libpuffs option parsing code and creating an puffs client, say, mount_puffs to be able to forward requests from one location to another. The puffs protocol should be extended to include the necessary new features or another protocol defined.
 
Index: wikisrc/projects/project/improved-automounter-support.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/improved-automounter-support.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/projects/project/improved-automounter-support.mdwn	18 Feb 2015 20:46:18 -0000	1.9
+++ wikisrc/projects/project/improved-automounter-support.mdwn	20 Feb 2015 16:42:42 -0000	1.10
@@ -20,7 +20,13 @@
 * File systems are not mounted directly on the desired mount point. As a result applications frequently use incorrect pathnames (e.g. `/amd/server/home/user` instead of `/home/user`) for automatically mounted directories or files beneath them. This is especially problematic in heterogeneous enviroments where not all machines use the same automounter.
 * The automounter daemon cannot handle high I/O load very well; file access occasionally fails with intermittent errors.
 
-The goal of this project is to implement a new automounter solution which addresses the above issues. This could either be done via a Solaris/Linux compatible autofs(4) full in-kernel file system. FreeBSD has already implemented autofs, so we could port theirs and that should significantly simplify the project. 
+The milestones of this project are:
+
+* implement a new automounter solution which has configurable mount points
+* improve high I/O
+* show benchmarks and implement automated tests
+
+This could either be done via a Solaris/Linux compatible autofs(4) full in-kernel file system. FreeBSD has already implemented autofs, so we could port theirs and that should significantly simplify the project. 
 """
 ]]
 
Index: wikisrc/projects/project/inetd-enhancements.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/inetd-enhancements.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/projects/project/inetd-enhancements.mdwn	18 Feb 2015 20:49:57 -0000	1.4
+++ wikisrc/projects/project/inetd-enhancements.mdwn	20 Feb 2015 16:42:42 -0000	1.5
@@ -15,19 +15,21 @@
 duration="3 months"
 
 description="""
-The following features should be added to inetd:
+Enhance inetd in NetBSD
+
+Primary milestones:
 
 - Prefork: Support pre-forking multiple children and keeping them alive for multiple invocations.
 - Per service configuration file: Add a per-service configuration file similar to xinetd.
 - Make the rate-limiting feature configurable on a per-service basis.
 - Improve the logging and make logging modes configurable on a per-service basis.
-- Integrate with the new blacklist daemon.
 
-Perhaps also some of the following:
+Nice to have:
 
 - Add include directives to the configuration language to allow service definitions to be installed in /usr/share or /usr/pkg/share.
 - Add a separate way to turn services on and off, so they can be defined statically (such as in /usr/share) and turned on and off from /etc.
 - Allow non-privileged users to add/remove/change their own services using a separate utility.
+- Integrate with the new blacklist daemon.
 - Configuration compatibility for systemd socket activations
 
 """
Index: wikisrc/projects/project/isdn-nt-asterisk.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/isdn-nt-asterisk.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/isdn-nt-asterisk.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/isdn-nt-asterisk.mdwn	20 Feb 2015 16:42:42 -0000	1.3
@@ -15,7 +15,11 @@
 duration="3 months"
 
 description="""
-This project has two subprojects: add support for the NT (network) side of ISDN to the NetBSD ISDN stack and interface ISDN (in NT mode) to the [Asterisk PBX](http://asterisk.org/), which would allow using existing ISDN PBXes as SIP/VoIP phones, as well as easier testing of new ISDN card drivers.
+This project has three milestones:
+
+* add support for the NT (network) side of ISDN to the NetBSD ISDN stack
+* interface ISDN (in NT mode) to the [Asterisk PBX](http://asterisk.org/), which would allow using existing ISDN PBXes as SIP/VoIP phones
+* show this makes it easier to test new ISDN card drivers
 
 Previous work in this area can be found at the [alternative ISDN driver site](http://www.turbocat.net/~hselasky/isdn4bsd/).
 """

Index: wikisrc/projects/project/u-boot-pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/u-boot-pkgsrc.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/u-boot-pkgsrc.mdwn	20 Feb 2015 16:32:13 -0000	1.1
+++ wikisrc/projects/project/u-boot-pkgsrc.mdwn	20 Feb 2015 16:38:57 -0000	1.2
@@ -33,6 +33,15 @@
 for loading from FFS file system to U-Boot. This would allow devices with SATA or USB disks to
 load the kernel directly from the root file system (while currently a wrappd .ub copy of the kernel
 has to be put into flash or on SD card).
+
+Deliverables of this project:
+
+1. Make U-Boot build on NetBSD, using a bsd style makefile and environment variables pointing at ${TOOLDIR}
+2. Discuss the changes needed for [1] with U-Boot upstream developers, follow their advice and try to upstream the changes
+3. Create a pkgsrc entry for the native U-Boot
+4. Add a FFS module to U-Boot, using NetBSD system headers
+
+Items [2] and [4] will not be required for GSoC success.
 """
 ]]
 

rename projects/project/u-boot__95__pkgsrc.mdwn to projects/project/u-boot-pkgsrc.mdwn
--- /dev/null	2015-02-20 16:32:00.000000000 +0000
+++ wikisrc/projects/project/u-boot-pkgsrc.mdwn	2015-02-20 16:32:23.000000000 +0000
@@ -0,0 +1,39 @@
+[[!template id=project
+
+title="Make u-boot compilable on NetBSD"
+
+contact="""
+[tech-toolchain](mailto:tech-toolchain@NetBSD.org)
+"""
+
+mentors="""
+[Martin Husemann](mailto:martin@NetBSD.org)
+"""
+
+category="userland"
+difficulty="medium"
+duration="3 months"
+
+description="""
+The U-Boot bootloader is being used by an increasing number of devices, including lots which run NetBSD.
+The NetBSD ${TOOLDIR} infrastructure even includes the mkubootimage program, which is used to wrap
+binaries (e.g. a kernel) into a packet understood by U-Boot.
+
+While the ${TOOLDIR} provides all toolchain bits needed (cross-compiler, assembler, linker, ...) and can
+be created by the build.sh script automatically for any supported architecture, U-Boot itself needs
+to be compiled natively on a Linux machine.
+
+The purpose of this project is to fix this, and feed as much as possible of the resulting
+changes upstream to the U-Boot developers.
+
+If possible, the result should be a pkgsrc package, that only needs to be pointed at a
+pre-populated tooldir for building. But a simple bsd style makefile would be good enough as well.
+
+An optional extension (but unlikely to be doable within the GSoC timescale): add support
+for loading from FFS file system to U-Boot. This would allow devices with SATA or USB disks to
+load the kernel directly from the root file system (while currently a wrappd .ub copy of the kernel
+has to be put into flash or on SD card).
+"""
+]]
+
+[[!tag gsoc]]
--- wikisrc/projects/project/u-boot__95__pkgsrc.mdwn	2015-02-20 16:32:23.000000000 +0000
+++ /dev/null	2015-02-20 16:32:00.000000000 +0000
@@ -1,39 +0,0 @@
-[[!template id=project
-
-title="Make u-boot compilable on NetBSD"
-
-contact="""
-[tech-toolchain](mailto:tech-toolchain@NetBSD.org)
-"""
-
-mentors="""
-[Martin Husemann](mailto:martin@NetBSD.org)
-"""
-
-category="userland"
-difficulty="medium"
-duration="3 months"
-
-description="""
-The U-Boot bootloader is being used by an increasing number of devices, including lots which run NetBSD.
-The NetBSD ${TOOLDIR} infrastructure even includes the mkubootimage program, which is used to wrap
-binaries (e.g. a kernel) into a packet understood by U-Boot.
-
-While the ${TOOLDIR} provides all toolchain bits needed (cross-compiler, assembler, linker, ...) and can
-be created by the build.sh script automatically for any supported architecture, U-Boot itself needs
-to be compiled natively on a Linux machine.
-
-The purpose of this project is to fix this, and feed as much as possible of the resulting
-changes upstream to the U-Boot developers.
-
-If possible, the result should be a pkgsrc package, that only needs to be pointed at a
-pre-populated tooldir for building. But a simple bsd style makefile would be good enough as well.
-
-An optional extension (but unlikely to be doable within the GSoC timescale): add support
-for loading from FFS file system to U-Boot. This would allow devices with SATA or USB disks to
-load the kernel directly from the root file system (while currently a wrappd .ub copy of the kernel
-has to be put into flash or on SD card).
-"""
-]]
-
-[[!tag gsoc]]

Index: wikisrc/projects/project/atf-sql-backend.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/atf-sql-backend.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/atf-sql-backend.mdwn	19 Feb 2015 19:43:46 -0000	1.1
+++ wikisrc/projects/project/atf-sql-backend.mdwn	19 Feb 2015 19:45:45 -0000	1.2
@@ -23,7 +23,7 @@
 Creating a suitable database schema and the xml loader/upload tool is the first half.
 
 Second part is using the collected results to display some nice web pages showing statistics and allowing dedicated queries, comparable
-to then query pages of typical bug tracking systems.
+to the query pages of typical bug tracking systems.
 
 This project has the following milestones, in this order:
 
@@ -33,7 +33,7 @@
 4. Enhance the upload tool (or create a second variant) for Kuya output. This part is optional
 5. Document the database schema, web site setup, and tool created.
 
-A huge set of ATF xml data will be provided, we assume that the student creates the database enviroment for local testing themselves.
+A huge set of ATF xml data will be provided, we assume that the student creates the database environment for local testing themselves.
 
 The result is planed to be deployed on TNF servers later, so it is of direct use for the community.
 This deployment is not part of the GSoC timeline.

rename projects/project/atf__95__sql__95__backend.mdwn to projects/project/atf-sql-backend.mdwn
--- /dev/null	2015-02-19 19:40:45.000000000 +0000
+++ wikisrc/projects/project/atf-sql-backend.mdwn	2015-02-19 19:43:48.000000000 +0000
@@ -0,0 +1,43 @@
+[[!template id=project
+
+title="Create an SQL backend and statisticics/query page for ATF test results"
+
+contact="""
+[tech-userlevel](mailto:tech-userlevel@NetBSD.org)
+"""
+
+mentors="""
+[Martin Husemann](mailto:martin@NetBSD.org)
+"""
+
+category="userland"
+difficulty="medium"
+duration="3 months"
+
+description="""
+We are currently running various regular [tests](http://releng.netbsd.org/test-results.html), both on emulators and real hardware.
+The results are generated in ATF (or maybe sometime later in Kuya) raw XML output format and then transformed via xslt into html.
+This is good enough to display single test run results, but does not provide any overview or comparison options accross different test runs or architectures.
+
+The target of this project is to provide a simmple 'upload' utility, that takes the xml input and inserts it into a remote PostgresSQL database.
+Creating a suitable database schema and the xml loader/upload tool is the first half.
+
+Second part is using the collected results to display some nice web pages showing statistics and allowing dedicated queries, comparable
+to then query pages of typical bug tracking systems.
+
+This project has the following milestones, in this order:
+
+1. Create and test a database schema (suitable for multiple architectures, and later migration to Kuya)
+2. Create a tool to read the ATF xml data and insert it into a database. This will be the half term milestone.
+3. Create a web site providing basic browsing/search options for the database
+4. Enhance the upload tool (or create a second variant) for Kuya output. This part is optional
+5. Document the database schema, web site setup, and tool created.
+
+A huge set of ATF xml data will be provided, we assume that the student creates the database enviroment for local testing themselves.
+
+The result is planed to be deployed on TNF servers later, so it is of direct use for the community.
+This deployment is not part of the GSoC timeline.
+"""
+]]
+
+[[!tag gsoc]]
--- wikisrc/projects/project/atf__95__sql__95__backend.mdwn	2015-02-19 19:43:48.000000000 +0000
+++ /dev/null	2015-02-19 19:40:45.000000000 +0000
@@ -1,43 +0,0 @@
-[[!template id=project
-
-title="Create an SQL backend and statisticics/query page for ATF test results"
-
-contact="""
-[tech-userlevel](mailto:tech-userlevel@NetBSD.org)
-"""
-
-mentors="""
-[Martin Husemann](mailto:martin@NetBSD.org)
-"""
-
-category="userland"
-difficulty="medium"
-duration="3 months"
-
-description="""
-We are currently running various regular [tests](http://releng.netbsd.org/test-results.html), both on emulators and real hardware.
-The results are generated in ATF (or maybe sometime later in Kuya) raw XML output format and then transformed via xslt into html.
-This is good enough to display single test run results, but does not provide any overview or comparison options accross different test runs or architectures.
-
-The target of this project is to provide a simmple 'upload' utility, that takes the xml input and inserts it into a remote PostgresSQL database.
-Creating a suitable database schema and the xml loader/upload tool is the first half.
-
-Second part is using the collected results to display some nice web pages showing statistics and allowing dedicated queries, comparable
-to then query pages of typical bug tracking systems.
-
-This project has the following milestones, in this order:
-
-1. Create and test a database schema (suitable for multiple architectures, and later migration to Kuya)
-2. Create a tool to read the ATF xml data and insert it into a database. This will be the half term milestone.
-3. Create a web site providing basic browsing/search options for the database
-4. Enhance the upload tool (or create a second variant) for Kuya output. This part is optional
-5. Document the database schema, web site setup, and tool created.
-
-A huge set of ATF xml data will be provided, we assume that the student creates the database enviroment for local testing themselves.
-
-The result is planed to be deployed on TNF servers later, so it is of direct use for the community.
-This deployment is not part of the GSoC timeline.
-"""
-]]
-
-[[!tag gsoc]]

Index: wikisrc/projects/project/atf__95__sql__95__backend.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/atf__95__sql__95__backend.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/atf__95__sql__95__backend.mdwn	19 Feb 2015 19:39:24 -0000	1.1
+++ wikisrc/projects/project/atf__95__sql__95__backend.mdwn	19 Feb 2015 19:40:57 -0000	1.2
@@ -1,6 +1,6 @@
 [[!template id=project
 
-title="Create an SQL backend and statisticics/query page"
+title="Create an SQL backend and statisticics/query page for ATF test results"
 
 contact="""
 [tech-userlevel](mailto:tech-userlevel@NetBSD.org)

--- /dev/null	2015-02-19 19:32:00.000000000 +0000
+++ wikisrc/projects/project/atf__95__sql__95__backend.mdwn	2015-02-19 19:39:29.000000000 +0000
@@ -0,0 +1,43 @@
+[[!template id=project
+
+title="Create an SQL backend and statisticics/query page"
+
+contact="""
+[tech-userlevel](mailto:tech-userlevel@NetBSD.org)
+"""
+
+mentors="""
+[Martin Husemann](mailto:martin@NetBSD.org)
+"""
+
+category="userland"
+difficulty="medium"
+duration="3 months"
+
+description="""
+We are currently running various regular [tests](http://releng.netbsd.org/test-results.html), both on emulators and real hardware.
+The results are generated in ATF (or maybe sometime later in Kuya) raw XML output format and then transformed via xslt into html.
+This is good enough to display single test run results, but does not provide any overview or comparison options accross different test runs or architectures.
+
+The target of this project is to provide a simmple 'upload' utility, that takes the xml input and inserts it into a remote PostgresSQL database.
+Creating a suitable database schema and the xml loader/upload tool is the first half.
+
+Second part is using the collected results to display some nice web pages showing statistics and allowing dedicated queries, comparable
+to then query pages of typical bug tracking systems.
+
+This project has the following milestones, in this order:
+
+1. Create and test a database schema (suitable for multiple architectures, and later migration to Kuya)
+2. Create a tool to read the ATF xml data and insert it into a database. This will be the half term milestone.
+3. Create a web site providing basic browsing/search options for the database
+4. Enhance the upload tool (or create a second variant) for Kuya output. This part is optional
+5. Document the database schema, web site setup, and tool created.
+
+A huge set of ATF xml data will be provided, we assume that the student creates the database enviroment for local testing themselves.
+
+The result is planed to be deployed on TNF servers later, so it is of direct use for the community.
+This deployment is not part of the GSoC timeline.
+"""
+]]
+
+[[!tag gsoc]]

Clarify terminology.
Index: wikisrc/kernel_debugging_with_qemu.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/kernel_debugging_with_qemu.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/kernel_debugging_with_qemu.mdwn	19 Feb 2015 08:32:23 -0000	1.8
+++ wikisrc/kernel_debugging_with_qemu.mdwn	19 Feb 2015 09:37:14 -0000	1.9
@@ -61,7 +61,7 @@
 ## Booting the VMs
 
 Next, start two qemu virtual machines, one to run the kernel being
-debugged (the "kgdb target") and another to run gdb (the "kgdb host").
+debugged (the "target VM") and another to run gdb (the "gdb VM").
 
 The two VMs could be run on separate physical machines, but in this
 example, they are run on the same physical machine and share the same
@@ -69,7 +69,7 @@
 option to qemu, which ensures that the disk image is not written to by
 either VM.
 
-First start the kgdb target, enabling qemu's built-in GDB target stub
+First start the target VM, enabling qemu's built-in GDB target stub
 on TCP port 1234:
 
 [[!template  id=programlisting text="""
@@ -80,20 +80,20 @@
 target, make sure incoming connections on port 1234 are blocked in
 your firewall.
 
-In a second terminal window, start the kgdb host:
+In a second terminal window, start the gdb VM:
 
 [[!template  id=programlisting text="""
  $ qemu-system-i386 -nographic -snapshot -hda work/wd0.img
 """]]
 
-Log in to the kgdb host as root and set up the network:
+Log in to the gdb VM as root and set up the network:
 
 [[!template  id=programlisting text="""
  login: root
  # dhcpcd
 """]]
 
-Start gdb on the kgdb host and connect to the target:
+Start gdb on the gdb VM and connect to the target:
 
 [[!template  id=programlisting text="""
  # gdb /netbsd
@@ -101,7 +101,7 @@
 """]]
 
 where my.host.name is the domain name or IP address of the
-physical machine running the kgdb target qemu VM.
+host system.
 
 Now you should be able to get a stack trace and start debugging
 with full debug symbols and access to the source code:

VMs, not VMS
Index: wikisrc/kernel_debugging_with_qemu.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/kernel_debugging_with_qemu.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/kernel_debugging_with_qemu.mdwn	18 Feb 2015 16:23:11 -0000	1.7
+++ wikisrc/kernel_debugging_with_qemu.mdwn	19 Feb 2015 08:32:23 -0000	1.8
@@ -63,7 +63,7 @@
 Next, start two qemu virtual machines, one to run the kernel being
 debugged (the "kgdb target") and another to run gdb (the "kgdb host").
 
-The two VMS could be run on separate physical machines, but in this
+The two VMs could be run on separate physical machines, but in this
 example, they are run on the same physical machine and share the same
 hard disk image.  This sharing is made possible by the "-snapshot"
 option to qemu, which ensures that the disk image is not written to by

Fix URL of presentation pages
Index: wikisrc/events.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/events.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/events.mdwn	26 Jun 2014 13:35:19 -0000	1.10
+++ wikisrc/events.mdwn	19 Feb 2015 07:06:37 -0000	1.11
@@ -3,7 +3,7 @@
 [contact us.](http://www.NetBSD.org/cgi-bin/feedback.cgi)
 
 For a list of NetBSD-related presentations, please check out our
-[presentation pages](/gallery/presentations/).
+[presentation pages](http://www.netbsd.org/gallery/presentations/).
 
 [Conference Attendance and Organizations](conferences)
 

add gsoc tag
Index: wikisrc/projects/project/raidframe-raid6.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/raidframe-raid6.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/raidframe-raid6.mdwn	18 Feb 2015 22:51:27 -0000	1.1
+++ wikisrc/projects/project/raidframe-raid6.mdwn	18 Feb 2015 22:51:55 -0000	1.2
@@ -18,3 +18,5 @@
 Test and debug the RAID 6 implementation in RAIDframe.
 """
 ]]
+
+[[!tag gsoc]]

<christos> another SoC: test raid 6 on raidframe and fix it.
--- /dev/null	2015-02-18 22:50:00.000000000 +0000
+++ wikisrc/projects/project/raidframe-raid6.mdwn	2015-02-18 22:51:31.000000000 +0000
@@ -0,0 +1,20 @@
+[[!template id=project
+
+title="raid 6 in RAIDframe"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org)
+"""
+
+mentors="""
+[Christos Zoulas](mailto:christos@NetBSD.org)
+"""
+
+category="filesystems"
+difficulty="medium"
+duration="unknown"
+
+description="""
+Test and debug the RAID 6 implementation in RAIDframe.
+"""
+]]

mention systemd
Index: wikisrc/projects/project/inetd-enhancements.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/inetd-enhancements.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/inetd-enhancements.mdwn	16 Feb 2015 07:05:15 -0000	1.3
+++ wikisrc/projects/project/inetd-enhancements.mdwn	18 Feb 2015 20:49:57 -0000	1.4
@@ -28,6 +28,7 @@
 - Add include directives to the configuration language to allow service definitions to be installed in /usr/share or /usr/pkg/share.
 - Add a separate way to turn services on and off, so they can be defined statically (such as in /usr/share) and turned on and off from /etc.
 - Allow non-privileged users to add/remove/change their own services using a separate utility.
+- Configuration compatibility for systemd socket activations
 
 """
 ]]

Remove me as a mentor.
Index: wikisrc/projects/project/improved-automounter-support.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/improved-automounter-support.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/projects/project/improved-automounter-support.mdwn	18 Feb 2015 20:18:19 -0000	1.8
+++ wikisrc/projects/project/improved-automounter-support.mdwn	18 Feb 2015 20:46:18 -0000	1.9
@@ -8,7 +8,6 @@
 """
 
 mentors="""
-[Matthias Scheler](mailto:tron@NetBSD.org)
 """
 
 category="kernel"

removed
--- wikisrc/projects/project/ptyfs_multiple_mounts.mdwn	2015-02-18 20:19:27.000000000 +0000
+++ /dev/null	2015-02-18 20:16:00.000000000 +0000
@@ -1,30 +0,0 @@
-[[!template id=project
-
-title="Enhance ptyfs to handle multiple instances"
-
-contact="""
-[tech-kern](mailto:tech-kern@NetBSD.org)
-"""
-
-mentors="""
-[Christos Zoulas](mailto:christos@NetBSD.org)
-"""
-
-category="kernel"
-difficulty="easy"
-duration="3 months"
-
-description="""
-Chrooted enviroments that need ptys cannot currently use ptyfs because only one instance of ptyfs at a time is supported. The task is to enhance ptyfs so that it can be mounted multiple times. The problems that need to be solved are:
-
-* The ptyfs code needs to be modified so that the correct path is returned depending on the mount point in the TIOCPTMGET ioctl. There was code there to do this, but it was removed because it was not working properly.
-* Since there can be only one instance of each major/minor pty in the system, each mount point should only display the ptys that were created on that mount point and not others.
-* ptyfs replaces the handlers for the traditional BSD style ptys when it is mounted and puts them back once it is unmounted. This handler hijacking will not work with multiple mounts. Perhaps a solution is to do it only for the first mount?
-
-This project is implemented all in the kernel and has no documentation requirements.
-
-For extra credit you can investigate if providing continuous numbers on each mount point (without gaps) is feasible without too much recoding, and implement it.
-"""
-]]
-
-[[!tag gsoc]]

--- /dev/null	2015-02-18 20:16:00.000000000 +0000
+++ wikisrc/projects/project/improved-automounter-support.mdwn	2015-02-18 20:18:22.000000000 +0000
@@ -0,0 +1,28 @@
+[[!template id=project
+
+title="Improved Automounter Support"
+
+contact="""
+[tech-kern](mailto:tech-net@NetBSD.org),
+[tech-net](mailto:tech-net@NetBSD.org)
+"""
+
+mentors="""
+[Matthias Scheler](mailto:tron@NetBSD.org)
+"""
+
+category="kernel"
+difficulty="medium"
+duration="3 months"
+
+description="""
+NetBSD currently uses amd for automatically mounting (network) file systems. This software package implements an automounter file system as a userland NFS daemon. While this generally works it has major drawbacks:
+
+* File systems are not mounted directly on the desired mount point. As a result applications frequently use incorrect pathnames (e.g. `/amd/server/home/user` instead of `/home/user`) for automatically mounted directories or files beneath them. This is especially problematic in heterogeneous enviroments where not all machines use the same automounter.
+* The automounter daemon cannot handle high I/O load very well; file access occasionally fails with intermittent errors.
+
+The goal of this project is to implement a new automounter solution which addresses the above issues. This could either be done via a Solaris/Linux compatible autofs(4) full in-kernel file system. FreeBSD has already implemented autofs, so we could port theirs and that should significantly simplify the project. 
+"""
+]]
+
+[[!tag gsoc]]

Remove "Improved Automounter Support". Nobody has volunteered for this
project in several years. And I will probably not have time to mentor
the project.
--- wikisrc/projects/project/improved-automounter-support.mdwn	2015-02-18 20:16:28.000000000 +0000
+++ /dev/null	2015-02-18 20:16:00.000000000 +0000
@@ -1,28 +0,0 @@
-[[!template id=project
-
-title="Improved Automounter Support"
-
-contact="""
-[tech-kern](mailto:tech-net@NetBSD.org),
-[tech-net](mailto:tech-net@NetBSD.org)
-"""
-
-mentors="""
-[Matthias Scheler](mailto:tron@NetBSD.org)
-"""
-
-category="kernel"
-difficulty="hard"
-duration="3 months"
-
-description="""
-NetBSD currently uses amd for automatically mounting (network) file systems. This software package implements an automounter file system as a userland NFS daemon. While this generally works it has major drawbacks:
-
-* File systems are not mounted directly on the desired mount point. As a result applications frequently use incorrect pathnames (e.g. `/amd/server/home/user` instead of `/home/user`) for automatically mounted directories or files beneath them. This is especially problematic in heterogeneous enviroments where not all machines use the same automounter.
-* The automounter daemon cannot handle high I/O load very well; file access occasionally fails with intermittent errors.
-
-The goal of this project is to implement a new automounter solution which addresses the above issues. This could either be done via a Solaris/Linux compatible autofs(4) full in-kernel file system or via a userland daemon using puffs. 
-"""
-]]
-
-[[!tag gsoc]]

Note amount of disk space needed
Index: wikisrc/kernel_debugging_with_qemu.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/kernel_debugging_with_qemu.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/kernel_debugging_with_qemu.mdwn	18 Feb 2015 16:03:37 -0000	1.6
+++ wikisrc/kernel_debugging_with_qemu.mdwn	18 Feb 2015 16:23:11 -0000	1.7
@@ -9,7 +9,8 @@
 (the "host system").
 This can be NetBSD itself, Linux, or some other Unix-like OS.
 These instructions have been tested with NetBSD/amd64 6.1.4 and
-Debian 7 hosts.
+Debian 7 hosts.   There should be at least 20 gigabytes of available
+disk space.
 
 If your host system is running NetBSD, install the following packages
 from pkgsrc:

Redirect automatically to new page.
Index: wikisrc/netbsd_kernel_development_setup.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/netbsd_kernel_development_setup.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/netbsd_kernel_development_setup.mdwn	18 Feb 2015 16:00:09 -0000	1.8
+++ wikisrc/netbsd_kernel_development_setup.mdwn	18 Feb 2015 16:12:36 -0000	1.9
@@ -1,3 +1,5 @@
+[[!meta redir="kernel_debugging_with_qemu"]]
+
 # Moved
 
 The instructions that used to be on this page have moved to

Duplicated word
Index: wikisrc/kernel_debugging_with_qemu.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/kernel_debugging_with_qemu.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/kernel_debugging_with_qemu.mdwn	18 Feb 2015 16:00:09 -0000	1.5
+++ wikisrc/kernel_debugging_with_qemu.mdwn	18 Feb 2015 16:03:37 -0000	1.6
@@ -7,7 +7,7 @@
 
 You need a computer running an OS capable of cross-building NetBSD
 (the "host system").
-This can be be NetBSD itself, Linux, or some other Unix-like OS.
+This can be NetBSD itself, Linux, or some other Unix-like OS.
 These instructions have been tested with NetBSD/amd64 6.1.4 and
 Debian 7 hosts.
 

Heavy-handed cleanup of the pages related to kernel debugging with
QEMU. There are two such pages:
https://wiki.netbsd.org/kernel_debugging_with_qemu/ didn't actually
contain any instructions for debugging with qemu, despite the name,
only instructions for creating a hard disk image for use qith qemu,
and even those where incomplete.
https://wiki.netbsd.org/netbsd_kernel_development_setup/, on the other
hand, did contain instructions for debugging with qemu, with two
alternative methods for setting up the disk image, one of which was a
duplicate of the incomplete instructions in kernel_debugging_with_qemu.
I have now updated the qemu debugging instructions to work with recent
versinos of qemu and -current, tested them on both NetBSD and Linux
hosts, and moved them to the kernel_debugging_with_qemu page to make
the page title better match the content. I also removed the
incomplete disk image creation instructions (from both places). The
netbsd_kernel_development_setup page is hereby obsoleted and now
contains only a reference to the kernel_debugging_with_qemu page.
https://wiki.netbsd.org/netbsd_kernel_development_setup/, on the other
hand, did contain instructions for debugging with qemu, with two
alternative methods for setting up the disk image, one of which was a
duplicate of the incomplete instructions in kernel_debugging_with_qemu.

I have now updated the qemu debugging instructions to work with recent
versinos of qemu and -current, tested them on both NetBSD and Linux
hosts, and moved them to the kernel_debugging_with_qemu page to make
the page title better match the content.  I also removed the
incomplete disk image creation instructions (from both places).  The
netbsd_kernel_development_setup page is hereby obsoleted and now
contains only a reference to the kernel_debugging_with_qemu page.

Members: 
	kernel_debugging_with_qemu.mdwn:1.4->1.5 
	netbsd_kernel_development_setup.mdwn:1.7->1.8 
	tutorials.mdwn:1.31->1.32 

Index: wikisrc/kernel_debugging_with_qemu.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/kernel_debugging_with_qemu.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/kernel_debugging_with_qemu.mdwn	31 Mar 2011 09:00:49 -0000	1.4
+++ wikisrc/kernel_debugging_with_qemu.mdwn	18 Feb 2015 16:00:09 -0000	1.5
@@ -1,123 +1,126 @@
 # Introduction
 
-Virtual machines are a convenient way to test, debug or even audit different systems on one single host. This is particularly helpful when you need to set up a machine for which you do not necessarily have the hardware, or the access, in a very cheap way, without risking breaking your day-to-day system.
+This HOWTO explains how to set up a test environment for symbolic
+debugging of the NetBSD kernel using a pair of QEMU virtual machines.
 
-This tutorial show the different steps required to set up a raw disk image like the one used by QEMU. It deals with two different point of views:
+## Prerequisites
 
-* the host, which is the machine and OS hosting the different VMs.
-* the guest(s), representing the different systems emulated/hosted on the host, through QEMU.
+You need a computer running an OS capable of cross-building NetBSD
+(the "host system").
+This can be be NetBSD itself, Linux, or some other Unix-like OS.
+These instructions have been tested with NetBSD/amd64 6.1.4 and
+Debian 7 hosts.
 
-# Setting up the environment
+If your host system is running NetBSD, install the following packages
+from pkgsrc:
 
-## Creating the raw disk image
+* emulators/qemu >= 2.0.0nb4
+* misc/py-anita
 
-To start our VM, we need some disk space to provide an emulated hard drive. For QEMU, by default, this is done through raw disk images. Therefore, the first step will be the creation of a disk image file. Here, we create a 2GB file, filled with zeros:
+If your host system uses a package system other than pkgsrc,
+use that to install cvs, make, gcc, qemu, the Python pexpect
+library, and genisoimage or mkisofs.  Also download and 
+install the most recent anita package from
+<http://www.gson.org/netbsd/anita/download/>.
 
-[[!template  id=programlisting text="""
-$ dd if=/dev/zero of=netbsd-guest.img bs=1m count=2000
-"""]]
-
-/!\ if you want to mount the file image from within the host later through [[!template id=man name="vnconfig" section="8"]], it is recommended to use [[!template id=man name="dd" section="1"]] and not the *qemu-img* tool, as [[!template id=man name="vnd" section="4"]] does not support sparse disk image yet.
+## Building the target system
 
-Now that the disk image file is ready, we will need to install our system inside.
+Check out the NetBSD-current sources from CVS and build a full
+NetBSD-current/i386 release with debug symbols using the build.sh
+script.  The i386 port is the preferred test platform because the two
+other ports supported by anita are affected by known bugs: amd64 by
+[[PR 49276|http://gnats.NetBSD.org/49276]], and sparc by
+[[qemu bug 1335444|https://bugs.launchpad.net/qemu/+bug/1335444]].
 
-## Preparing the MBR, labels, and first stage boot loader
-
-Mount the image file as a [[!template id=man name="vnd" section="4"]] device. This will allow manipulating the image file just like a regular hard disk drive:
+If you do the build in a directory other than /usr/src, 
+use the -fdebug-prefix-map option to ensure that the source file names embedded
+in the debug symbols point to /usr/src, which is where the sources will be
+installed on the target system.  For example:
 
 [[!template  id=programlisting text="""
-# vnconfig -c vnd0 netbsd-guest.img
+ $ CVSROOT=anoncvs@anoncvs.NetBSD.org:/cvsroot cvs checkout -A -P src
+ $ cd src
+ $ ./build.sh -j 4 -V MKDEBUG=YES -V COPTS="-g -fdebug-prefix-map=$(pwd)=/usr/src" -O ../obj -m i386 -U release sourcesets
 """]]
 
-### Creating MBR
+For best performance, change the number after "-j" to the number of CPU cores
+you have, or slightly more.
 
-Setup the MBR; it musts contain the NetBSD partition. This will be done interactively via [[!template id=man name="fdisk" section="8"]]:
+## Installing the target system
 
-[[!template  id=programlisting text="""
-# fdisk -u -a -0 /dev/rvnd0
-Disk: /dev/rvnd0d
-[...]
-Do you want to change our idea of what BIOS thinks? [n] *n*
+Install the system in a virtual machine, including the debug symbols and source code:
 
-Partition 0:
-<UNUSED>
-The data for partition 0 is:
-<UNUSED>
-sysid: [0..255 default: 169] *press enter*
-start: [0..255dcyl default: 63, 0dcyl, 0MB] *press enter*
-size: [0..255dcyl default: 4095937, 255dcyl, 2000MB] *press enter*
-bootmenu: [] *press enter*
-Do you want to change the active partition? [n] *y*
-Choosing 4 will make no partition active.
-active partition: [0..4 default: 0] *press enter*
-Are you happy with this choice? [n] *y*
-We haven't written the MBR back to disk yet.  This is your last chance.
-Partition table:
-0: NetBSD (sysid 169)
-    start 63, size 4095937 (2000 MB, Cyls 0-254/245/55), Active
-        PBR is not bootable: All bytes are identical (0x00)
-1: <UNUSED>
-2: <UNUSED>
-3: <UNUSED>
-Bootselector disabled.
-First active partition: 0
-Should we write new partition table? [n] *y*
+[[!template  id=programlisting text="""
+ $ cd ..
+ $ anita --workdir work --disk-size 4G --memory-size 256M \
+     --sets kern-GENERIC,modules,base,etc,comp,debug,games,man,misc,tests,text,syssrc,src,sharesrc,gnusrc \
+     install $(pwd)/obj/releasedir/i386/
 """]]
 
-### Editing labels
+## Booting the VMs
 
-Edit the labels, with [[!template id=man name="disklabel" section="8"]]. The example below will create:
+Next, start two qemu virtual machines, one to run the kernel being
+debugged (the "kgdb target") and another to run gdb (the "kgdb host").
 
-* label **a**, approximately 1.5GiB long -- will contain the future FFS / partition
-* label **b**, 512MiB swap.
+The two VMS could be run on separate physical machines, but in this
+example, they are run on the same physical machine and share the same
+hard disk image.  This sharing is made possible by the "-snapshot"
+option to qemu, which ensures that the disk image is not written to by
+either VM.
+
+First start the kgdb target, enabling qemu's built-in GDB target stub
+on TCP port 1234:
 
 [[!template  id=programlisting text="""
-# disklabel -e -I /dev/rvnd0
-[...]
-4 partitions:
-#        size    offset     fstype [fsize bsize cpg/sgs]
- a:   3047361        63     4.2BSD      0     0     0  # (Cyl.      0*-   1487)
- b:   1048576   3047424       swap                     # (Cyl.   1488 -   1999)
- d:   4096000         0     unused      0     0        # (Cyl.      0 -   1999)
+ $ qemu-system-i386 -nographic -snapshot -hda work/wd0.img -gdb tcp::1234
 """]]
 
-### Copying first stage boot loader
+If you don't want everyone on the Internet to be able to debug your
+target, make sure incoming connections on port 1234 are blocked in
+your firewall.
 
-Lastly, we have to install the first stage boot loader, the one that will be able to read the second stage boot loader, which will reside in partition **a**. Use [[!template id=man name="installboot" section="8"]]:
+In a second terminal window, start the kgdb host:
 
 [[!template  id=programlisting text="""
-# installboot /dev/rvnd0a /usr/mdec/bootxx_ffsv2
+ $ qemu-system-i386 -nographic -snapshot -hda work/wd0.img
 """]]
 
-## Format and mount the filesystem
-
-With [[!template id=man name="newfs" section="8"]], format label **a** in FFSv2:
+Log in to the kgdb host as root and set up the network:
 
 [[!template  id=programlisting text="""
-# newfs -O2 /dev/rvnd0a
-/dev/rvnd0a: 1488.0MB (3047360 sectors) block size 16384, fragment size 2048
-	using 9 cylinder groups of 165.34MB, 10582 blks, 20544 inodes.
-super-block backups (for fsck_ffs -b #) at:
-160, 338784, 677408, 1016032, 1354656, 1693280, 2031904, 2370528, 2709152,
+ login: root
+ # dhcpcd
 """]]
 
-then [[!template id=man name="mount" section="8"]] it:
+Start gdb on the kgdb host and connect to the target:
 
 [[!template  id=programlisting text="""
-# mkdir /tmp/netbsd-guest
-# mount /dev/vnd0a /tmp/netbsd-guest
+ # gdb /netbsd
+ (gdb) target remote my.host.name:1234
 """]]
 

(Diff truncated)
phil@ says: analysis completed, No code to move data, rest not in shape to commit.
Index: wikisrc/projects/project/defrag_ffs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/defrag_ffs.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/projects/project/defrag_ffs.mdwn	17 Feb 2015 07:58:48 -0000	1.6
+++ wikisrc/projects/project/defrag_ffs.mdwn	17 Feb 2015 20:39:01 -0000	1.7
@@ -8,7 +8,6 @@
 
 category="filesystems"
 difficulty="medium"
-done_by="Manuel Wiesinger"
 
 description="""
 Heavily used file systems tend to spread the blocks all over the disk,

Index: wikisrc/projects/project/defrag_ffs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/defrag_ffs.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/projects/project/defrag_ffs.mdwn	16 Feb 2015 04:04:05 -0000	1.5
+++ wikisrc/projects/project/defrag_ffs.mdwn	17 Feb 2015 07:58:48 -0000	1.6
@@ -8,6 +8,7 @@
 
 category="filesystems"
 difficulty="medium"
+done_by="Manuel Wiesinger"
 
 description="""
 Heavily used file systems tend to spread the blocks all over the disk,

Index: wikisrc/projects/gsoc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/gsoc.mdwn,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- wikisrc/projects/gsoc.mdwn	9 Feb 2015 19:47:00 -0000	1.16
+++ wikisrc/projects/gsoc.mdwn	17 Feb 2015 01:14:35 -0000	1.17
@@ -1,6 +1,6 @@
 [[!meta title="Google Summer of Code project proposals"]]
 
-<!-- NetBSD participated successfully in all of Google's Summer of Code
+NetBSD participated successfully in all of Google's Summer of Code
 programs up to 2013 (see our results of
 [2005](http://www.netbsd.org/foundation/press/soc-summary.html),
 [2006](http://www.netbsd.org/foundation/press/soc2006-summary.html),

JTAG poject is not a pkgsrc project.
Categorize as misc.
Index: wikisrc/projects/project/jtag_kit.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/jtag_kit.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/jtag_kit.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/jtag_kit.mdwn	16 Feb 2015 09:43:02 -0000	1.3
@@ -10,7 +10,7 @@
 [Matthias Drochner](mailto:drochner@NetBSD.org)
 """
 
-category="pkgsrc"
+category="misc"
 difficulty="hard"
 duration="3 months"
 

Also mention IIJ
Index: wikisrc/gitsofar.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/gitsofar.mdwn	16 Feb 2015 01:51:16 -0000	1.5
+++ wikisrc/gitsofar.mdwn	16 Feb 2015 08:36:53 -0000	1.6
@@ -103,7 +103,7 @@
 
 ### Who, When, and How Long?
 
-* ESR/Joerg - convert
+* ESR/IIJ/Joerg - convert
 * sometime, eventually, maybe
 * assumptions/proposal:
 

<joerg> kill it, packagekit is dead
--- wikisrc/projects/project/pkgsrc_packagekit.mdwn	2015-02-16 07:59:54.000000000 +0000
+++ /dev/null	2015-02-16 07:50:00.000000000 +0000
@@ -1,52 +0,0 @@
-[[!template id=project
-
-title="Add pkgsrc support to packagekit"
-
-contact="""
-[tech-pkg](mailto:tech-pkg@NetBSD.org)
-"""
-
-mentors="""
-[Thomas Klausner](mailto:wiz@NetBSD.org), [Emile 'iMil' Heitor](mailto:imil@NetBSD.org)
-"""
-
-category="pkgsrc"
-difficulty="medium"
-duration="3 months"
-
-description="""
-Add pkgsrc support to [packagekit](http://www.packagekit.org/pk-intro.html) so the graphical packaging software "just works" for pkgsrc
-
-The pkgsrc/pkgtools/packagekit package currently contains a minimal implementation of pkgsrc support to get the package to compile.
-This should be extended.
-
-Useful steps:
-
-* Show all installed packages and let the user delete them
-* Show list of available packages (local/remote) and let the user add them
-* Show lists of available updates
-* Include security information, i.e. show recommended updates based on audit-packages and list of installed / available packages
-
-Additional goals:
-
-* Show progress and / or console while installing / upgrading
-* pkgsrc's PackageKit backend is to be integrated upstream (PackageKit people are open to contributions, that won't be an issue)
-* It must not be mandatory to install the pkgsrc source tree (binary packages-only needs to work)
-* If installation / upgrade hits a package not available as a binary (typically packages where the license doesn't allow distribution in binary form, e.g. flash, mplayer-share, ...), try to fallback to the pkgsrc source tree if it is available and explain causes and consequences to the user. That could be part of pkgin instead of the PackageKit backend.
-* In case of failure, the full log shall be displayed so that the user has a chance to fix the problem "by hand". Some explanations about the failure would be nice. A useful log is mandatory in order to be able to request help from the pkgsrc-users mailing list or to open a PR.
-* Using a convenient programming language, the student shall write an abstraction layer / API, permitting to easily manipulate pkgsrc.
-
-    This layer shall permit to :
-
-    * Return pkgsrc version
-    * Return an installed package list/map
-    * Return a "to-upgrade" package list/map
-    * Return a full "package map" (non-automatic + dependencies)
-    * Return an available package list
-    * Install/upgrade/remove a new package and its dependencies
-    * Return information about a package (DESCR, version, PLIST, Makefile, options, ...)
-    * Display security information
-"""
-]]
-
-[[!tag gsoc]]

Note that this partly exists now.
Index: wikisrc/projects/project/bulktracker.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/bulktracker.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/bulktracker.mdwn	9 Apr 2012 00:36:13 -0000	1.2
+++ wikisrc/projects/project/bulktracker.mdwn	16 Feb 2015 07:52:31 -0000	1.3
@@ -78,5 +78,9 @@
 packages where for whatever reason the package name does not match the
 pkgsrc directory. The best key seems to be the pkgsrc directory paired
 with the package-name-without-version.
+
+Some code already exists for this, written in Python using Postgres.
+Writing new code (rather than working on this existing code) is
+probably not a good plan.
 """
 ]]

who am I kidding; this project is hard. in fact, more like "impossible"
Index: wikisrc/projects/project/user-switching.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/user-switching.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/user-switching.mdwn	2 Apr 2014 15:24:58 -0000	1.1
+++ wikisrc/projects/project/user-switching.mdwn	16 Feb 2015 07:49:46 -0000	1.2
@@ -8,7 +8,7 @@
 """
 
 category="desktop"
-difficulty="medium"
+difficulty="hard"
 
 description="""
 In MacOS X, while logged in on the desktop, you can switch to another

This project is "hard". it's not even clearly specified
Index: wikisrc/projects/project/c_refactoring_aid.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/c_refactoring_aid.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/c_refactoring_aid.mdwn	6 Nov 2011 14:48:47 -0000	1.3
+++ wikisrc/projects/project/c_refactoring_aid.mdwn	16 Feb 2015 07:17:54 -0000	1.4
@@ -11,7 +11,7 @@
 """
 
 category="userland"
-difficulty="medium"
+difficulty="hard"
 duration="3 months"
 
 description="""
@@ -28,5 +28,10 @@
 something helpful with break, continue, and return statements.
 
 That's just a start.
+
+This project is tagged "hard" because it's not clearly specified.
+The first step (like with many projects) is to work out the
+specification in more detail.
+
 """
 ]]

duration 1 month -> 2 months
(I might be able to do this in one month but I've worked on make before)
Index: wikisrc/projects/project/bsdmake-enhancements.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/bsdmake-enhancements.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/bsdmake-enhancements.mdwn	27 Feb 2014 08:38:07 -0000	1.3
+++ wikisrc/projects/project/bsdmake-enhancements.mdwn	16 Feb 2015 07:15:45 -0000	1.4
@@ -8,7 +8,7 @@
 
 category="userland"
 difficulty="medium"
-duration="1 month"
+duration="2 months"
 
 description="""
 

note that this should support multiple user interfaces
(that is, the baseline version needs to be something that fits in base
but also we should have a nice-looking gtk frontend)
Index: wikisrc/projects/project/wifi-tool.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/wifi-tool.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/wifi-tool.mdwn	6 Nov 2011 21:08:23 -0000	1.2
+++ wikisrc/projects/project/wifi-tool.mdwn	16 Feb 2015 07:13:57 -0000	1.3
@@ -14,5 +14,10 @@
 description="""
 Create an easy to use wifi setup widget for NetBSD: browse and select networks
 in the vicinity by SSID, BSSID, channel, etc.
+
+The guts should probably be done as a library so that user interfaces
+of increasing slickness can be built on top of it as desired.
+(That is: there ought to be some form of this in base; but a nice
+looking gtk interface version would be good to have as well.)
 """
 ]]

Add some stuff.
Index: wikisrc/projects/project/inetd-enhancements.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/inetd-enhancements.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/inetd-enhancements.mdwn	6 Nov 2011 14:48:47 -0000	1.2
+++ wikisrc/projects/project/inetd-enhancements.mdwn	16 Feb 2015 07:05:15 -0000	1.3
@@ -19,7 +19,15 @@
 
 - Prefork: Support pre-forking multiple children and keeping them alive for multiple invocations.
 - Per service configuration file: Add a per-service configuration file similar to xinetd.
-- Ability for non privileged users to add/remove/change their own services using a separate utility.
+- Make the rate-limiting feature configurable on a per-service basis.
+- Improve the logging and make logging modes configurable on a per-service basis.
+- Integrate with the new blacklist daemon.
+
+Perhaps also some of the following:
+
+- Add include directives to the configuration language to allow service definitions to be installed in /usr/share or /usr/pkg/share.
+- Add a separate way to turn services on and off, so they can be defined statically (such as in /usr/share) and turned on and off from /etc.
+- Allow non-privileged users to add/remove/change their own services using a separate utility.
 
 """
 ]]

Add some more notes, and mention that the upper interface to this thing
is a block device. (thus fully obsoleting nand-flash.mdwn which I just
removed)
Index: wikisrc/projects/project/flash-translation.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/flash-translation.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/flash-translation.mdwn	16 Feb 2015 06:18:18 -0000	1.3
+++ wikisrc/projects/project/flash-translation.mdwn	16 Feb 2015 06:57:11 -0000	1.4
@@ -32,5 +32,21 @@
 There are also some research FTLs that we might be able to get the
 code for; it is probably worth looking into this.
 
+Note that NAND flash and NOR flash are different and need different
+handling, and the various cell types and other variations also warrant
+different policy choices.
+
+The degree of overprovisioning (that is, the ratio of the raw capacity
+of the flash chips to the advertised size of the resulting device)
+should be configurable as this is a critical factor for performance.
+
+Making the device recoverable rather than munching itself in system
+crashes or power failures is a nice extra, although apparently the
+market considers this an optional feature for consumer devices.
+
+The flash translation layer should probably be packaged a driver that
+attaches to one or more flash chips and provides a disk-type
+block/character device pair.
+
 """
 ]]

Delete this project; it has no description.
Also, it's a trivial extension of the flash translation layer project.
Members: 
	projects/project/nand-flash.mdwn:1.2->1.3(DEAD) 

--- wikisrc/projects/project/nand-flash.mdwn	2015-02-16 06:51:20.000000000 +0000
+++ /dev/null	2015-02-16 06:50:00.000000000 +0000
@@ -1,16 +0,0 @@
-[[!template id=project
-
-title="NetBSD block device driver for NAND flash chips"
-
-contact="""
-[tech-embed](mailto:tech-embed@NetBSD.org)
-"""
-
-category="kernel"
-difficulty="hard"
-duration="2 months"
-
-description="""
-
-"""
-]]

Addressed this comment; it doesn't need to hang around any further.
--- wikisrc/projects/project/kernel_continuations/comment_1_68899534975b138b6eef727a557fd937._comment	2015-02-16 06:47:36.000000000 +0000
+++ /dev/null	2015-02-16 06:40:01.000000000 +0000
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawknlyJnJpKKKA2Q0TJzA5blhn8l2cTJ8Hs"
- nickname="Louis Philippe"
- subject="Continuations?"
- date="2011-11-27T20:58:06Z"
- content="""
-Maybe you should explain a bit more what is a Continuations.
-"""]]

Clarify that these "continuations" are not continuations; they're
callbacks.
I'm aware that there's a body of practice that uses the term
"continuations" for these constructions, presumably because they can
be used (if used in a certain stylized way) to manually and painfully
implement what you might otherwise do with callcc. But in conventional
usage they aren't continuations or anything like continuations.
Note that I'm not going so far as to change the name or anything
(although I'd suggest that in the long run), just adding a
clarification.
If anyone wants to argue this you know where to find me :-)
Note that I'm not going so far as to change the name or anything
(although I'd suggest that in the long run), just adding a
clarification.

If anyone wants to argue this you know where to find me :-)

Members: 
	projects/project/kernel_continuations.mdwn:1.2->1.3 

Index: wikisrc/projects/project/kernel_continuations.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/kernel_continuations.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/kernel_continuations.mdwn	8 Feb 2012 14:18:15 -0000	1.2
+++ wikisrc/projects/project/kernel_continuations.mdwn	16 Feb 2015 06:46:30 -0000	1.3
@@ -21,6 +21,11 @@
 reworded as: combine *callouts*, *softints*, and *workqueues* into a single
 framework.  Continuations are meant to be cheap; very cheap.
 
+These continuations are a dispatching system for making callbacks at
+scheduled times or in different thread/interrupt contexts.
+They aren't "continuations" in the usual sense such as you might find
+in Scheme code.
+
 Please note that the main goal of this project is to simplify the
 implementation of [[SMP networking|smp_networking]], so care must be taken
 in the design of the interface to support all the features required for

This is more tech-kern than tech-net business.
Index: wikisrc/projects/project/improved-automounter-support.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/improved-automounter-support.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/projects/project/improved-automounter-support.mdwn	27 Feb 2014 08:09:16 -0000	1.5
+++ wikisrc/projects/project/improved-automounter-support.mdwn	16 Feb 2015 06:35:37 -0000	1.6
@@ -3,6 +3,7 @@
 title="Improved Automounter Support"
 
 contact="""
+[tech-kern](mailto:tech-net@NetBSD.org),
 [tech-net](mailto:tech-net@NetBSD.org)
 """
 

NOPE try again
Index: wikisrc/projects/project/improve-caching.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/improve-caching.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/projects/project/improve-caching.mdwn	16 Feb 2015 06:30:39 -0000	1.4
+++ wikisrc/projects/project/improve-caching.mdwn	16 Feb 2015 06:31:14 -0000	1.5
@@ -45,11 +45,12 @@
 Step 1 is to just find all the things in the kernel that ought to
 participate in a coordinated caching and scheduling scheme. This
 should not take all that long. Some examples include:
- * UVM pages
- * file system metadata buffers
- * VFS name cache
- * vnode cache
- * size of the mbuf pool
+
+* UVM pages
+* file system metadata buffers
+* VFS name cache
+* vnode cache
+* size of the mbuf pool
 
 Step 2 is to restructure and connect things up so that it is readily
 possible to get the necessary information from all the random places

flog markup
Index: wikisrc/projects/project/improve-caching.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/improve-caching.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/improve-caching.mdwn	27 Feb 2014 08:04:16 -0000	1.3
+++ wikisrc/projects/project/improve-caching.mdwn	16 Feb 2015 06:30:39 -0000	1.4
@@ -45,11 +45,11 @@
 Step 1 is to just find all the things in the kernel that ought to
 participate in a coordinated caching and scheduling scheme. This
 should not take all that long. Some examples include:
-* UVM pages
-* file system metadata buffers
-* VFS name cache
-* vnode cache
-* size of the mbuf pool
+ * UVM pages
+ * file system metadata buffers
+ * VFS name cache
+ * vnode cache
+ * size of the mbuf pool
 
 Step 2 is to restructure and connect things up so that it is readily
 possible to get the necessary information from all the random places

Add a project for an mlock() that can be used by databases for their
journals.
--- /dev/null	2015-02-16 06:20:01.000000000 +0000
+++ wikisrc/projects/project/mlockin.mdwn	2015-02-16 06:27:44.000000000 +0000
@@ -0,0 +1,30 @@
+[[!template id=project
+
+title="Locking pages into memory, redux"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org)
+"""
+
+category="kernel"
+difficulty="medium"
+duration="1-2 months"
+
+description="""
+The mlock() system call locks pages in memory; however, it's meant for
+real-time applications that wish to avoid _pageins_.
+
+There's a second class of applications that want to lock pages in
+memory: databases and anything else doing journaling, logging, or
+ordered writes of any sort want to lock pages in memory to avoid
+_pageouts_.
+That is, it should be possible to lock a (dirty) page in memory so
+that it does not get written out until after it's unlocked.
+
+It is a bad idea to try to make mlock() serve this purpose as well as
+the purpose it already serves, so add a new call, perhaps mlockin(),
+and implement support in UVM.
+
+Then for extra credit ram it through POSIX and make Linux implement it :-)
+"""
+]]

As a flash translation layer is a storage project, move it to "filesystems".
It is more likely to be found there by people interested in it.
Also, it is tech-kern business as well as tech-embed.
Members: 
	projects/project/flash-translation.mdwn:1.2->1.3 

Index: wikisrc/projects/project/flash-translation.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/flash-translation.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/flash-translation.mdwn	27 Feb 2014 07:18:03 -0000	1.2
+++ wikisrc/projects/project/flash-translation.mdwn	16 Feb 2015 06:18:18 -0000	1.3
@@ -3,10 +3,11 @@
 title="Flash translation layer"
 
 contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org),
 [tech-embed](mailto:tech-embed@NetBSD.org)
 """
 
-category="kernel"
+category="filesystems"
 difficulty="medium"
 
 description="""

note the tls-maxphys branch explicitly.
Index: wikisrc/projects/project/buffer-queue.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/buffer-queue.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/buffer-queue.mdwn	27 Feb 2014 06:57:54 -0000	1.3
+++ wikisrc/projects/project/buffer-queue.mdwn	16 Feb 2015 06:13:12 -0000	1.4
@@ -20,6 +20,7 @@
 
 There is currently work in progress to make MAXPHYS configured at
 runtime based on driver capability.
+At least some of it is committed on the tls-maxphys branch.
 
 This project originaly suggested instead to make the buffer queue
 management logic (which currently only sorts the queue, aka disksort)

fix busted link
Index: wikisrc/projects/project/sgimipsr10k.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/sgimipsr10k.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/sgimipsr10k.mdwn	6 Nov 2011 19:58:46 -0000	1.1
+++ wikisrc/projects/project/sgimipsr10k.mdwn	16 Feb 2015 06:04:56 -0000	1.2
@@ -14,6 +14,6 @@
 example speculative loads are not handled correctly.  It is unclear if this is
 pure kernel work or the toolchain needs to be changed too.
 
-See also [NetBSD/sgimips](../ports/sgimips/).
+See also [NetBSD/sgimips](../../ports/sgimips/).
 """
 ]]

use right category name
Index: wikisrc/projects/project/pubsub-sockets.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/pubsub-sockets.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/pubsub-sockets.mdwn	16 Feb 2015 05:56:51 -0000	1.1
+++ wikisrc/projects/project/pubsub-sockets.mdwn	16 Feb 2015 05:58:17 -0000	1.2
@@ -8,7 +8,7 @@
 [David Holland](mailto:dholland@NetBSD.org)
 """
 
-category="net"
+category="networking"
 difficulty="hard"
 
 description="""

Add a project for my publish/subscribe sockets idea.
--- /dev/null	2015-02-16 05:50:01.000000000 +0000
+++ wikisrc/projects/project/pubsub-sockets.mdwn	2015-02-16 05:56:56.000000000 +0000
@@ -0,0 +1,53 @@
+[[!template id=project
+
+title="Publish-subscribe Unix sockets"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org),
+[tech-net](mailto:tech-net@NetBSD.org),
+[David Holland](mailto:dholland@NetBSD.org)
+"""
+
+category="net"
+difficulty="hard"
+
+description="""
+Add publish-subscribe sockets to AF_UNIX (filesystem sockets).
+
+The idea of a publish-subscribe socket (as opposed to a traditional
+socket) is that anything written to one end is read out by _all_
+processes reading from the other end.
+
+This raises some issues that need attention; most notably, if a
+process doesn't read data sent to it, how long do we wait (or how much
+data do we allow to accumulate) before dropping the data or
+disconnecting that process?
+
+It seems that one would want to be able to have both SOCK_STREAM and
+SOCK_DGRAM publish/subscribe channels, so it isn't entirely clear yet
+how best to graft this functionality into the socket API.
+Or the socket code.
+It might end up needing to be its own thing instead, or needing to
+extend the socket API, which would be unfortunate but perhaps
+unavoidable.
+
+The goal for these sockets is to provide a principled and robust
+scheme for passing notices around.
+This will allow replacing multiple existing ad hoc callback schemes
+(such as for notices of device insertions) and also to allow various
+signaling schemes among user processes that have never been very
+workable in Unix.
+Those who remember AREXX will recognize the potential; but of course
+it will take time before anything like that can be orchestrated.
+
+For this reason it's important that it be reasonably easy for one of
+the endpoints to be inside the kernel; but it's also important that
+peer credentials and permissions work.
+
+Another goal is to be able to use publish/subscribe sockets to provide
+a compatibility library for Linux desktop software that wants to use
+dbus or any successor to dbus.
+
+I'm marking this project hard as it's still only about half baked.
+"""
+]]

Add a project entry for execute-in-place.
--- /dev/null	2015-02-16 05:20:01.000000000 +0000
+++ wikisrc/projects/project/xip.mdwn	2015-02-16 05:29:34.000000000 +0000
@@ -0,0 +1,29 @@
+[[!template id=project
+
+title="Execute in place support"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org),
+[tech-embed](mailto:tech-embed@NetBSD.org)
+"""
+
+category="kernel"
+difficulty="medium"
+duration="2-3 months"
+
+description="""
+Add support to UVM to allow processes to map pages directly from
+underlying objects that are already mapped into memory: for example,
+files in tmpfs; files in mfs; and also files on memory-mapped storage
+devices, like raw flash chips or experimental storage-class memory
+hardware.
+
+This allows accesses (most notably, execution of user programs) to go
+directly to the backing object without copying the pages into main
+system memory.
+(Which in turn has obvious advantages.)
+
+Note that uebayasi@ was working on this at one point but his changes
+did not get merged.
+"""
+]]

Add an entry for tmpfs quotas.
--- /dev/null	2015-02-16 05:16:00.000000000 +0000
+++ wikisrc/projects/project/tmpfs-quotas.mdwn	2015-02-16 05:18:54.000000000 +0000
@@ -0,0 +1,17 @@
+[[!template id=project
+
+title="Per-user memory limits for tmpfs"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org)
+"""
+
+category="filesystems"
+difficulty="medium"
+duration="2 months"
+
+description="""
+Add per-user memory usage limits (also known as "quotas") to tmpfs,
+using the existing quota system infrastructure.
+"""
+]]

add a project entry for removing KERNEL_LOCK from scsipi
--- /dev/null	2015-02-16 05:16:00.000000000 +0000
+++ wikisrc/projects/project/scsipi-locking.mdwn	2015-02-16 05:16:18.000000000 +0000
@@ -0,0 +1,18 @@
+[[!template id=project
+
+title="Proper locking in scsipi"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org)
+"""
+
+category="filesystems"
+difficulty="medium"
+duration="1 month"
+
+description="""
+Currently the scsipi subsystem is kernel-locked.
+This should not be.
+Please to fix :-)
+"""
+]]

Add a project for transparent full-disk encryption
--- /dev/null	2015-02-16 05:10:04.000000000 +0000
+++ wikisrc/projects/project/transparent-cgd.mdwn	2015-02-16 05:13:11.000000000 +0000
@@ -0,0 +1,51 @@
+[[!template id=project
+
+title="Transparent full-disk encryption"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org)
+"""
+
+category="filesystems"
+difficulty="medium"
+duration="2 months"
+
+description="""
+While currently we have the cgd(4) driver for encrypting disks,
+setting it up is fairly involved.
+Furthermore, while it's fairly easy to use it just for /home, in an
+ideal world the entire disk should be encrypted; this leads to some
+nontrivial bootstrapping problems.
+
+Develop a scheme for mounting root on cgd that does not require
+explicit manual setup, that passes cryptographic muster, and that
+protects everything on the root volume except for what absolutely must
+be exposed.
+Implement it.
+
+The following is a non-exhaustive list of issues to consider:
+ * How should we tell when root should be on cgd (perhaps in boot.cfg?)
+ * When (and how) do we enter the passphrase needed to mount root (at mount-root time? in the bootloader? after mounting a fake root?)
+ * Key management for the encryption passphrase
+ * Where to keep the bootloader and/or kernels
+ * Should the bootloader be able to read the cgd to get the boot kernel from it?
+ * If the kernel is not on cgd, should it be signed to allow the bootloader to verify it?
+ * Integration with sysinst so all you need to do to get FDE is to hit a checkbox
+ * Perhaps, making it easy or at least reasonably possible to migrate an unencrypted root volume to cgd
+
+Note that while init(8) currently has a scheme for mounting a
+temporary root and then chrooting to the real root afterwards, it
+doesn't work all that well.
+Improving it is somewhat difficult; also, ideally init(8) would be on
+the encrypted root volume.
+It would probably be better to support mounting the real root directly
+on cgd.
+
+Another option is a pivot_root type of operation like Linux has, which
+allows mounting a fake root first and then shuffling the mount points
+to move something else into the / position.
+This has its drawbacks as well, and again ideally there would be no
+unencrypted fake root volume.
+
+"""
+]]

flog markup
Index: wikisrc/projects/project/aio.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/aio.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/aio.mdwn	16 Feb 2015 04:39:29 -0000	1.1
+++ wikisrc/projects/project/aio.mdwn	16 Feb 2015 04:40:28 -0000	1.2
@@ -31,7 +31,7 @@
 
 This is a big project.
 
-Note that the [[flow control|tcp-writing.mdwn]] project, which also
+Note that the [[flow control|tcp-writing]] project, which also
 requires substantial revisions to the I/O path, naturally combines
 with this project.
 """

Add "get us real AIO" project (filesystem; hard)
--- /dev/null	2015-02-16 04:32:00.000000000 +0000
+++ wikisrc/projects/project/aio.mdwn	2015-02-16 04:39:32.000000000 +0000
@@ -0,0 +1,38 @@
+[[!template id=project
+
+title="Real asynchronous I/O"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org)
+"""
+
+category="filesystems"
+difficulty="hard"
+duration="2-3 months"
+
+description="""
+The current asynchronous I/O (aio) implementation works by forking a
+background thread inside the kernel to do the I/O synchronously.
+This is potentially an adequate starting point, but one thread limits
+the amount of potential parallelism, and adding more threads falls
+down badly when applications want to have large numbers of requests
+outstanding at once.
+
+Furthermore, the existing code doesn't even work in some cases; this
+is not well documented but there have been scattered reports of
+problems that nobody had time to look into in detail.
+
+In order to make asynchronous I/O work well, the I/O path needs to be
+revised (particularly at the lower levels) so that all I/O operations
+are asynchronous requests by default.
+It is easy for high-level code to wait synchronously for lower-level
+asynchronous requests to complete; it is much more problematic for an
+asynchronous request to call into code that expects to be synchronous.
+
+This is a big project.
+
+Note that the [[flow control|tcp-writing.mdwn]] project, which also
+requires substantial revisions to the I/O path, naturally combines
+with this project.
+"""
+]]

Add missing difficulty tag, and edit some.
Index: wikisrc/projects/project/ext4fs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/ext4fs.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/ext4fs.mdwn	14 Feb 2015 07:02:40 -0000	1.1
+++ wikisrc/projects/project/ext4fs.mdwn	16 Feb 2015 04:25:25 -0000	1.2
@@ -7,14 +7,19 @@
 """
 
 category="filesystems"
+difficulty="hard"
 
 description="""
-The Ext4 file system is starndard file system for Linux (recent Ubuntu,
-and somewhat old Fedora). And sucessor of Ext3 file system.
+The Ext4 file system is standard file system for Linux (recent Ubuntu,
+and somewhat old Fedora). It is the successor of the Ext3 file system.
 
-It has journaling, larger size of file system, and improved timestamp etc
+It has journaling, larger file system volumes, and improved timestamp etc
 features.
 
-The NetBSD kernel support and accompanied userland code should be written.
+The NetBSD kernel support and accompanying userland code should be written.
+
+It is not clear at the moment if this should be done by working on the
+existing ext2 code or not, and if not, whether it should be integrated
+with the ufs code or not.
 """
 ]]

better title.
Index: wikisrc/projects/project/tcp-writing.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/tcp-writing.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/projects/project/tcp-writing.mdwn	16 Feb 2015 04:21:09 -0000	1.4
+++ wikisrc/projects/project/tcp-writing.mdwn	16 Feb 2015 04:21:58 -0000	1.5
@@ -1,6 +1,6 @@
 [[!template id=project
 
-title="Improve writing to the file system"
+title="Flow control for writing to the file system"
 
 contact="""
 [tech-kern](mailto:tech-kern@NetBSD.org)

Ramble a bit about why this is filed as "hard"
Index: wikisrc/projects/project/tcp-writing.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/tcp-writing.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/tcp-writing.mdwn	27 Feb 2014 08:16:38 -0000	1.3
+++ wikisrc/projects/project/tcp-writing.mdwn	16 Feb 2015 04:21:09 -0000	1.4
@@ -14,5 +14,11 @@
 Apply TCP-like flow control to processes writing to the filesystem (put them to
 sleep when there is "congestion"), to avoid enormous backlogs and provide more
 fair allocation of disk bandwidth.
+
+This is a nontrivial undertaking as the I/O path wasn't intended to
+support this type of throttling. Also, the throttle should be
+underneath all caching (there is nothing to be gained by throttling
+cached accesses) but by that point attributing I/O actions to specific
+processes is awkward.
 """
 ]]

Warn that ext3 is harder than people think and has failed in the past.
Index: wikisrc/projects/project/ext3fs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/ext3fs.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/projects/project/ext3fs.mdwn	27 Feb 2014 05:15:23 -0000	1.4
+++ wikisrc/projects/project/ext3fs.mdwn	16 Feb 2015 04:14:01 -0000	1.5
@@ -21,6 +21,7 @@
 The ext3 support should be implemented by extending the existing ext2 support (which is in src/sys/ufs/ext2fs), not by rewriting the whole thing over from scratch. It is possible that some of the ostensibly filesystem-independent code that was added along with the ffs WAPBL journaling extensions might be also useable as part of an ext3 implementation; but it also might not be.
 
 The full requirements for this project include complete support for ext3 in both the kernel and the userland tools. It is possible that a reduced version of this project with a clearly defined subset of these requirements could still be a viable GSOC project; if this appeals to you please coordinate with a prospective mentor.
+Be advised, however, that several past ext3-related GSOC projects have failed; it is a harder undertaking than you might think.
 
 An additional useful add-on goal would be to audit the locking in the existing ext2 code; the ext2 code is not tagged MPSAFE, meaning it uses a biglock on multiprocessor machines, but it is likely that either it is in fact already safe and just needs to be tagged, or can be easily fixed. (Note that while this is not itself directly related to implementing ext3, auditing the existing ext2 code is a good way to become familiar with it.)
 """

Mention safety concern: can't trash the volume if you crash while
defragging.
Index: wikisrc/projects/project/defrag_ffs.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/defrag_ffs.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/projects/project/defrag_ffs.mdwn	27 Feb 2014 06:33:07 -0000	1.4
+++ wikisrc/projects/project/defrag_ffs.mdwn	16 Feb 2015 04:04:05 -0000	1.5
@@ -18,5 +18,8 @@
 The resize_ffs code already contains logic for relocating blocks, as
 it needs to be able to do that to shrink a volume; it is likely that
 it would serve nicely as a starting point for a defragmenting tool.
+
+Note that safety (not scrambling the volume if the system crashes
+while defragging) is somewhat tricky and critically important.
 """
 ]]

Clarify the descriptions of the index pages. The "all" ones always confuse
me every time I come here.
Index: wikisrc/projects.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/projects.mdwn	21 Mar 2012 12:10:31 -0000	1.10
+++ wikisrc/projects.mdwn	16 Feb 2015 03:56:50 -0000	1.11
@@ -23,16 +23,16 @@
 
 # General indexes
 
-* [[All projects, one per page|/projects/all]].  Broken down by category and difficulty.
-* [[All projects, one page|/projects/all-flat]].  Includes an Atom/RSS feed providing notifications of changes to any project.
+* [[All projects (index)|/projects/all]].  Broken down by category and difficulty.
+* [[All projects (one big page)|/projects/all-flat]].  Includes an Atom/RSS feed providing notifications of changes to any project.
 * [[Funded projects|/projects/funded]].  These projects have been pre-approved for monetary funding.
 * [[Brainstorming of project proposals|/projects/ideas]].  Be aware that the projects in this page are not well-defined.  They are just additional ideas that you may want to consider.
 * [[Completed projects|/projects/done]].  The archive of completed projects, for reference purposes only.  You may not send applications for these.
 
 # Program-specific indexes
 
-* [[Google Summer of Code|gsoc]]
-* [[Google Code-In|code-in]] (contains some ideas)
+* [[Projects suitable for Google Summer of Code|gsoc]]
+* [[Projects for Google Code-In|code-in]] (contains some ideas)
 
 # Add a project
 

Add IEEE 802.3 Clause 45, IEEE802.3az, PCI extended configuration space, dot3 MIB and daily autotest system for ARM.
Index: wikisrc/projects/ideas.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/ideas.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/ideas.mdwn	15 Feb 2015 04:34:36 -0000	1.3
+++ wikisrc/projects/ideas.mdwn	16 Feb 2015 03:55:40 -0000	1.4
@@ -57,6 +57,15 @@
 
 1. Update zfs pool to version 5000.
 
+1. Add MI interface for IEEE 802.3 Clause 45 MDIO access.
+
+1. IEEE 802.3az(Energy Efficiency Ethernet(EEE)) support.
+
+1. To be able to map and access PCI extended configuration space.
+
+1. Add Support dot3 MIB.
+
+
 # Userspace Projects
 
 1. a Java implementation we can use across all netbsd platforms
@@ -87,6 +96,8 @@
 
 1. Stack Backtrace Library - Write a library that the kernel debugger and return_address(9) can use to walk down the call stack.  Use the technique that [David Laight](mailto:dsl@NetBSD.org) recommends: TBD.
 
+1. Daily autotest system for ARM
+
 # pkgsrc projects
 
 1. Modular libtool: rewrite libtool replacement that is faster and more convenient to maintain, so that one can add compilers to it without rebuilding the whole package.

update
Index: wikisrc/users/msaitoh.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/msaitoh.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/users/msaitoh.mdwn	5 Feb 2015 04:12:12 -0000	1.10
+++ wikisrc/users/msaitoh.mdwn	16 Feb 2015 03:47:14 -0000	1.11
@@ -17,9 +17,9 @@
 * Change the return value of mii_readreg() and mii_writereg().
     * Currently there is no way to know whether the call was failed(timeout) or not.
 * IEEE 802.3az (Energy Efficiency Ethernet(EEE)) supprot
-*
 * wm(4)
-    * SFP ROM support to work with SFP Copper module.
+    * SFP support.
+         * The code was written but it doesn't work yet :-|
 * Improve puc(4) as console
 * Update IXP4xx stuff.
 * Support Intel Galileo
@@ -31,10 +31,10 @@
 * To be able to map and access PCI extended configuration space.
     * PLEASE SOMEONE!
 * PCI MSI, MSI-X support
+    * knakahara@ is working on it.
 * Add support dot3 MIB
     * Steal from FreeBSD :)
 * Think about the behavior of ETHERCAP_*
-* Use MI kern/subr_disk_mbr.c on some ARM platforms <<http://gnats.netbsd.org/47463>>.
 * Fix/improve pmc(1) and PERFCTRS. At least it doesn't work on i386 MP system.
 * MI(or common) format or API for "cpuctl identify"
 * [[Comparison of implementations of Ethernet drivers]](ethernet_driver)

Index: wikisrc/gitsofar.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/gitsofar.mdwn	16 Feb 2015 01:44:18 -0000	1.4
+++ wikisrc/gitsofar.mdwn	16 Feb 2015 01:51:16 -0000	1.5
@@ -22,7 +22,8 @@
 change.  It will produce a warning with tunable options if the command runs
 slowly.
 
-** Update
+*Update*
+
 After some complaining on the git@ mailing list a patch has been produced which
 drops the memory requirements down quite a bit.  I can now, without much tuning,
 work on my 512 system.  I'm pretty sure a 256 + swap without any special tuning
@@ -110,7 +111,8 @@
 refinements of Joerg/ESR conversion can continue to run in read-only mode as they
 do today.  This means the "switch" is a few hours only for:
 
-** cvs goes read only
-** history from last git conversion pull until now is appended
-** cvs is turned off
-** git is made available over ssh
+1. cvs goes read only
+2. history from last git conversion pull until now is appended
+3. cvs is turned off
+4. git is made available over ssh
+

a few updates on git
Index: wikisrc/gitsofar.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/gitsofar.mdwn	1 Feb 2015 02:32:12 -0000	1.3
+++ wikisrc/gitsofar.mdwn	16 Feb 2015 01:44:18 -0000	1.4
@@ -22,6 +22,12 @@
 change.  It will produce a warning with tunable options if the command runs
 slowly.
 
+** Update
+After some complaining on the git@ mailing list a patch has been produced which
+drops the memory requirements down quite a bit.  I can now, without much tuning,
+work on my 512 system.  I'm pretty sure a 256 + swap without any special tuning
+would also work.
+
 ### CVS in parallel
 
 I do not think this is a good idea and do not plan to advocate for it.
@@ -74,7 +80,7 @@
 
 ### log message formats
 
-Try to references named branches instead of sha-1's
+Try to references named branches/tags instead of sha-1's
 Also using the dates for commits instead of commit id's
 
 ### how to convert
@@ -89,8 +95,22 @@
 Maybe when we have 30 years of project history it will be time to consider
 restructuring the project.  :)
 
+---
+
+I think this is less a function of the tool and more a function of the project not
+allowing non-"standard" actions.
+
 ### Who, When, and How Long?
 
 * ESR/Joerg - convert
 * sometime, eventually, maybe
-* unknown
+* assumptions/proposal:
+
+Assuming conversion starting from date(x) to freeze(y) is relatively easy, the
+refinements of Joerg/ESR conversion can continue to run in read-only mode as they
+do today.  This means the "switch" is a few hours only for:
+
+** cvs goes read only
+** history from last git conversion pull until now is appended
+** cvs is turned off
+** git is made available over ssh

Added VirtualBox and ZFS as project proposals.
Index: wikisrc/projects/ideas.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/ideas.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/ideas.mdwn	1 Jan 2013 01:44:13 -0000	1.2
+++ wikisrc/projects/ideas.mdwn	15 Feb 2015 04:34:36 -0000	1.3
@@ -55,6 +55,8 @@
 
 1. Improve tmpfs
 
+1. Update zfs pool to version 5000.
+
 # Userspace Projects
 
 1. a Java implementation we can use across all netbsd platforms
@@ -94,3 +96,5 @@
 1. Add support for multi-packages (building multiple binary packages from single source).
 > don't we do that already? (I guess this means: more info please :-) -- spz
 >> No, we don't. We don't produce more than one package during the single build.
+
+1. Running VirtualBox on NetBSD as a host.

Add DTrace theme.
--- /dev/null	2015-02-14 07:12:09.000000000 +0000
+++ wikisrc/projects/project/dtrace-syscall.mdwn	2015-02-14 07:14:17.000000000 +0000
@@ -0,0 +1,17 @@
+[[!template id=project
+
+title="DTrace syscall provider"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org),
+"""
+
+category="kern"
+
+description="""
+NetBSD has preliminary DTrace support, so it supports SDT and FBT provider
+only.
+
+riz@ has syscall provider patch.
+"""
+]]

Add ext4 file system support theme.
--- /dev/null	2015-02-14 07:02:43.000000000 +0000
+++ wikisrc/projects/project/ext4fs.mdwn	2015-02-14 07:02:44.000000000 +0000
@@ -0,0 +1,20 @@
+[[!template id=project
+
+title="Implement Ext4 file system support"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org)
+"""
+
+category="filesystems"
+
+description="""
+The Ext4 file system is starndard file system for Linux (recent Ubuntu,
+and somewhat old Fedora). And sucessor of Ext3 file system.
+
+It has journaling, larger size of file system, and improved timestamp etc
+features.
+
+The NetBSD kernel support and accompanied userland code should be written.
+"""
+]]

Add Broadcom WiFi Adapter support theme.
--- /dev/null	2015-02-14 07:01:15.000000000 +0000
+++ wikisrc/projects/project/brcmsmac-brcmfmac-wifi-driver.mdwn	2015-02-14 07:01:27.000000000 +0000
@@ -0,0 +1,20 @@
+[[!template id=project
+
+title="Support Broadcom BCM43* WiFi adapters"
+
+contact="""
+[tech-kern](mailto:tech-kern@NetBSD.org)
+"""
+
+category="kernel"
+
+description="""
+brcmsmac and brcmfmac WiFi device drivers for Linux supports
+BCM43XX and BCM43XXX based WiFi adapters.
+
+And source code is included in [Linux kernel tree](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/brcm80211),
+but it is licensed under ISC license.
+
+You can find these devices on Apple MacBook.
+"""
+]]

Add Xilinx MicroBlaze RISC processort support theme.
--- /dev/null	2015-02-14 07:00:26.000000000 +0000
+++ wikisrc/projects/project/microblaze.mdwn	2015-02-14 07:00:26.000000000 +0000
@@ -0,0 +1,15 @@
+[[!template id=project
+
+title="Support Xilinx MicroBlaze FPGA processor based evaluation boards"
+
+contact="""
+[tech-ports](mailto:tech-ports@NetBSD.org)
+"""
+
+category="ports"
+
+description="""
+Xilinx MicroBlaze is RISC processort for Xilinx's FPGA chip.
+MicroBlaze can have MMU, and NetBSD can support it.
+"""
+]]

Add Apache OpenOffice packaging theme.
--- /dev/null	2015-02-14 06:57:31.000000000 +0000
+++ wikisrc/projects/project/pkgsrc-apache-openoffice.mdwn	2015-02-14 06:57:45.000000000 +0000
@@ -0,0 +1,20 @@
+[[!template id=project
+
+title="Packaging Apache OpenOffice productivity suite to pkgsrc"
+
+contact="""
+[tech-pkg](mailto:tech-pkg@NetBSD.org)
+"""
+
+category="pkgsrc"
+difficulty="medium"
+
+description="""
+[Apache OpenOffice](https://www.openoffice.org/) is another child of
+OpenOffice.org.
+Apache OpenOffice is licensed under Apache License 2.
+
+Another child, LibreOffice licensed under LGPL3 is categorized
+as pkgsrc/misc/libreoffice4.
+"""
+]]

Add Chromium web browser (open source edition of Google Chrome) theme.
--- /dev/null	2015-02-14 06:55:41.000000000 +0000
+++ wikisrc/projects/project/pkgsrc-chromium.mdwn	2015-02-14 06:55:41.000000000 +0000
@@ -0,0 +1,22 @@
+[[!template id=project
+
+title="Porting Chromium web browser to NetBSD"
+
+contact="""
+[tech-pkg](mailto:tech-pkg@NetBSD.org)
+"""
+
+category="pkgsrc"
+difficulty="medium"
+
+description="""
+Google Chrome is widely used nowadays, and it has some state-of-the-art
+functionalities.
+
+[Chromium web browser](http://www.chromium.org/Home) is open source
+edition of Google Chrome.
+
+FreeBSD Ports has Chromium package
+as [www/chromium](https://svnweb.freebsd.org/ports/head/www/chromium/).
+"""
+]]

After integrating Percival's scripts (done by jym@), writing a tutorial
for AMI building and all the work done by riz@ to provide updated AMIs
on a regular basis (thanks!), AWS project can be considered completed.
Index: wikisrc/projects/project/aws-images.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/aws-images.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/aws-images.mdwn	6 Nov 2011 14:48:47 -0000	1.3
+++ wikisrc/projects/project/aws-images.mdwn	13 Feb 2015 18:21:27 -0000	1.4
@@ -13,6 +13,7 @@
 category="userland"
 difficulty="medium"
 duration="3 months"
+done_by="riz"
 
 description="""
 

Note that xenstored cannot be usefully restarted.
Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.87
retrieving revision 1.88
diff -u -r1.87 -r1.88
--- wikisrc/ports/xen/howto.mdwn	28 Jan 2015 19:27:11 -0000	1.87
+++ wikisrc/ports/xen/howto.mdwn	10 Feb 2015 17:38:14 -0000	1.88
@@ -401,6 +401,18 @@
 different.  TODO: add example output for xl before the xm example,
 after confirming on 4.2 and resolving the TODO about rc.conf.
 
+### Issues with xencommons
+
+xencommons starts xenstored, which stores data on behalf of dom0 and
+domUs.  It does not currently work to stop and start xenstored.
+Certainly all domUs should be shutdown first, following the sort order
+of the rc.d scripts.  However, the dom0 sets up state with xenstored,
+and is not notified when xenstored exits, leading to not recreating
+the state when the new xenstored starts.  Until there's a mechanism to
+make this work, one should not expect to be able to restart xenstored
+(and thus xencommons).  There is currently no reason to expect that
+this will get fixed any time soon.
+
 anita (for testing NetBSD)
 --------------------------
 

Update for 2015.
Index: wikisrc/projects/gsoc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/gsoc.mdwn,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- wikisrc/projects/gsoc.mdwn	24 Feb 2014 20:05:12 -0000	1.15
+++ wikisrc/projects/gsoc.mdwn	9 Feb 2015 19:47:00 -0000	1.16
@@ -1,7 +1,7 @@
 [[!meta title="Google Summer of Code project proposals"]]
 
 <!-- NetBSD participated successfully in all of Google's Summer of Code
-programs to date (see our results of
+programs up to 2013 (see our results of
 [2005](http://www.netbsd.org/foundation/press/soc-summary.html),
 [2006](http://www.netbsd.org/foundation/press/soc2006-summary.html),
 [2007](http://www.netbsd.org/foundation/press/soc2007-summary.html),
@@ -11,8 +11,7 @@
 [2011](http://blog.netbsd.org/tnf/entry/netbsd_s_google_summer_of),
 [2012](http://blog.netbsd.org/tnf/entry/netbsd_s_google_summer_of1),
 [2013](http://blog.netbsd.org/tnf/entry/netbsd_s_google_summer_of2)) and
-we are hope to once again participate as a mentoring organization in 2014. -->
-*** NetBSD is not participating as a mentoring organisation in 2014. ***
+we are hoping to once again participate as a mentoring organization in 2015.
 
 This page contains a list of concrete suggestions for projects we would
 like to see applications for in the next Summer of Code. Note that they

Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	6 Feb 2015 11:55:05 -0000	1.34
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	8 Feb 2015 21:10:46 -0000	1.35
@@ -118,7 +118,7 @@
  - Plug in a USB HID compatible Gamepad, such as the Logitech F710 in "DirectInput" mode (set "D/X" switch to "D").
  - Create a config file for your gamepad using *retroarch-joyconfig*.
 [[!template  id=programlisting text="""
-$ retroarch-joyconfig -o gamepad.cfg -a
+$ retroarch-joyconfig -o gamepad.cfg
 """]]
  - Launch the emulator from the command-line (no X required):
 [[!template  id=programlisting text="""

Add OpenSXCE
Index: wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn	8 Feb 2015 01:40:31 -0000	1.4
+++ wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn	8 Feb 2015 06:11:30 -0000	1.5
@@ -21,3 +21,6 @@
 
     # pkg install illumos-gcc gnu-binutils system/header developer/library/lint object-file header-math
     # PATH=/opt/gcc/4.4.4/bin:/usr/gnu/bin:$PATH pkgsrc/bootstrap/bootstrap
+
+#OpenSXCE
+Comes with all necessary component to bootstrap pkgsrc out of the box, just ensure <code>PATH</code> contains the path to GCC & linker <code>/opt/gcc/4.4.4/bin:/usr/gnu/bin</code> when performing a system wide install as root. No changes required when performing an [unprivileged bootstrap](http://www.netbsd.org/docs/pkgsrc/platforms.html#bootstrapping-pkgsrc) as environment contains necessary settings.

Add OpenIndiana, mention the Joyent binary repos, don't forget mention the develop overlay
Index: wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn	7 Feb 2015 05:29:27 -0000	1.3
+++ wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn	8 Feb 2015 01:40:31 -0000	1.4
@@ -1,10 +1,11 @@
 This page will cover the requirement to bootstrap pkgsrc successfully on Illumos based Solarish systems.  
+[Prebuilt binaries & a repository of packages is provided by Joyent](http://pkgsrc.joyent.com) so it is not necessary to go through this process unless by choice.  
 It is assumed that a copy of the pkgsrc files have been [obtained](http://pkgsrc.org/#index3h1) and uncompressed, ready to bootstrap.
 
 #OmniOS
 At the time of writing the latest build available was r151012 which had GCC 4.8.x available.  
 
-On a freshly installed system the only components needed to bootstrap pkgsrc successfully is GCC, lint, linker and header files.
+On a freshly installed system the only components needed to bootstrap pkgsrc successfully is GCC, lint, linker object-files and header files.
 
     # pkg install gcc48 header linker lint object-file header-math
 
@@ -13,4 +14,10 @@
 #Tribblix
 All that's required is for the <code>develop</code> overlay to be installed in order to successfully bootstrap pkgsrc on Tribblix.
 
-    # zap install-overlay
+    # zap install-overlay develop
+
+#OpenIndiana
+On the 151a8 development release of OpenIndiana, the installation of GCC & GNU binutils is required alongside lint, object-files and header files to bootstrap pkgsrc successfully.
+
+    # pkg install illumos-gcc gnu-binutils system/header developer/library/lint object-file header-math
+    # PATH=/opt/gcc/4.4.4/bin:/usr/gnu/bin:$PATH pkgsrc/bootstrap/bootstrap

Don't use html tags, use the correct markdown formatting for code instead
Index: wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn	7 Feb 2015 05:15:32 -0000	1.2
+++ wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn	7 Feb 2015 05:29:27 -0000	1.3
@@ -6,12 +6,11 @@
 
 On a freshly installed system the only components needed to bootstrap pkgsrc successfully is GCC, lint, linker and header files.
 
-<pre><code># pkg install gcc48 header linker lint object-file header-math</pre></code>
+    # pkg install gcc48 header linker lint object-file header-math
 
 pkgsrc can then be bootstrapped as [normal](http://www.netbsd.org/docs/pkgsrc/platforms.html#bootstrapping-pkgsrc)  
 
 #Tribblix
 All that's required is for the <code>develop</code> overlay to be installed in order to successfully bootstrap pkgsrc on Tribblix.
 
-<pre><code># zap install-overlay</pre></code>
-
+    # zap install-overlay

Add Tribblix
Index: wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn	7 Feb 2015 05:02:54 -0000	1.1
+++ wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn	7 Feb 2015 05:15:32 -0000	1.2
@@ -1,5 +1,5 @@
-This page will cover how to get up and running on Illumos based Solarish systems.  
-It is assumed that a copy of the pkgsrc files have been [obtained](http://pkgsrc.org/#index3h1) and uncompressed already, ready to bootstrap.
+This page will cover the requirement to bootstrap pkgsrc successfully on Illumos based Solarish systems.  
+It is assumed that a copy of the pkgsrc files have been [obtained](http://pkgsrc.org/#index3h1) and uncompressed, ready to bootstrap.
 
 #OmniOS
 At the time of writing the latest build available was r151012 which had GCC 4.8.x available.  
@@ -9,3 +9,9 @@
 <pre><code># pkg install gcc48 header linker lint object-file header-math</pre></code>
 
 pkgsrc can then be bootstrapped as [normal](http://www.netbsd.org/docs/pkgsrc/platforms.html#bootstrapping-pkgsrc)  
+
+#Tribblix
+All that's required is for the <code>develop</code> overlay to be installed in order to successfully bootstrap pkgsrc on Tribblix.
+
+<pre><code># zap install-overlay</pre></code>
+

Add OmniOS
--- /dev/null	2015-02-07 05:00:00.000000000 +0000
+++ wikisrc/pkgsrc/How_to_use_pkgsrc_on_Solarish___40__Illumos_based__41__.mdwn	2015-02-07 05:02:57.000000000 +0000
@@ -0,0 +1,11 @@
+This page will cover how to get up and running on Illumos based Solarish systems.  
+It is assumed that a copy of the pkgsrc files have been [obtained](http://pkgsrc.org/#index3h1) and uncompressed already, ready to bootstrap.
+
+#OmniOS
+At the time of writing the latest build available was r151012 which had GCC 4.8.x available.  
+
+On a freshly installed system the only components needed to bootstrap pkgsrc successfully is GCC, lint, linker and header files.
+
+<pre><code># pkg install gcc48 header linker lint object-file header-math</pre></code>
+
+pkgsrc can then be bootstrapped as [normal](http://www.netbsd.org/docs/pkgsrc/platforms.html#bootstrapping-pkgsrc)  

Start documenting bootstrapping pkgsrc on Illumos based distributions
Index: wikisrc/pkgsrc/how_to_use_pkgsrc.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/pkgsrc/how_to_use_pkgsrc.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/pkgsrc/how_to_use_pkgsrc.mdwn	30 Jan 2015 07:53:02 -0000	1.4
+++ wikisrc/pkgsrc/how_to_use_pkgsrc.mdwn	7 Feb 2015 04:23:35 -0000	1.5
@@ -102,3 +102,4 @@
 * [[How to use pkgsrc on Mac OS X]
 * [[How to use pkgsrc on OSF1]]
 * [[How to use pkgsrc on Solaris]]
+* [[How to use pkgsrc on Solarish (Illumos based)]]

Do not suggest using the HEAD build from nbftp, netbsd-7 works fine.
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	6 Feb 2015 02:05:41 -0000	1.33
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	6 Feb 2015 11:55:05 -0000	1.34
@@ -10,11 +10,10 @@
 
 # Installation
  - You may use the rpi.img file created by an evbarm build - evbarm-earmv6hf is recommended.
-   - The Raspberry Pi port will be part of the NetBSD 7 stable release,
-     but you may want to use the HEAD branch for the latest development code.
-   - The automatic nightly builds can be found in the 'evbarm-earmv6hf/binary/gzimg/' directory under on [nyftp.netbsd.org](http://nyftp.netbsd.org/pub/NetBSD-daily/).
-     - The HEAD/current build will be under HEAD/YYYYMMDDHHMMZ/evbarm-earmv6hf/binary/gzimg/
+   - The Raspberry Pi port will be part of the NetBSD 7 release.
+   - The automatic nightly builds can be found in the 'evbarm-earmv6hf/binary/gzimg/' directory on [nyftp.netbsd.org](http://nyftp.netbsd.org/pub/NetBSD-daily/).
      - The stable build will be under netbsd-7/YYYYMMDDHHMMZ/evbarm-earmv6hf/binary/gzimg/
+     - The HEAD/current build will be under HEAD/YYYYMMDDHHMMZ/evbarm-earmv6hf/binary/gzimg/
      - For example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201412161700Z/evbarm-earmv6hf/binary/gzimg/
    - 'releasedir/evbarm/binary/gzimg/' if you run (for example) './build.sh -m evbarm -a earmv6hf -u release'
    - <i>gunzip and dd</i> this img to your sd card.

Remove outdated "Additional links" section.
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	5 Feb 2015 23:39:59 -0000	1.32
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	6 Feb 2015 02:05:41 -0000	1.33
@@ -126,9 +126,6 @@
 $ retroarch --appendconfig gamepad.cfg -L /usr/pkg/lib/libretro/gambatte_libretro.so game.gbc
 """]]
 
-# Additional links
- - [ARM userland utilities](https://github.com/jaredmcneill/userland)
-
 # What works (NetBSD 7.0+)
  - multi-user boot with root on SD card
  - serial or graphics console (with EDID query / parsing)

RetroArch setup
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	4 Feb 2015 05:17:05 -0000	1.31
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	5 Feb 2015 23:39:59 -0000	1.32
@@ -111,6 +111,21 @@
 
 Place the pak0.pk3 file in the /usr/pkg/lib/ioquake3/baseq3 directory.
 
+## RetroArch / Libretro
+Using [emulators/retroarch](http://pkgsrc.se/emulators/retroarch) it is possible to run many emulators at full speed the Raspberry Pi. Emulator cores for various gaming consoles are available in the [emulators/libretro-*](http://pkgsrc.se/search.php?so=libretro-) packages. To begin using retroarch:
+
+ - Install [emulators/retroarch](http://pkgsrc.se/emulators/retroarch)
+ - Install the libretro core for the system you would like to emulate (lets take [emulators/libretro-gambatte](http://pkgsrc.se/emulators/libretro-gambatte), a GameBoy Color emulator, as an example).
+ - Plug in a USB HID compatible Gamepad, such as the Logitech F710 in "DirectInput" mode (set "D/X" switch to "D").
+ - Create a config file for your gamepad using *retroarch-joyconfig*.
+[[!template  id=programlisting text="""
+$ retroarch-joyconfig -o gamepad.cfg -a
+"""]]
+ - Launch the emulator from the command-line (no X required):
+[[!template  id=programlisting text="""
+$ retroarch --appendconfig gamepad.cfg -L /usr/pkg/lib/libretro/gambatte_libretro.so game.gbc
+"""]]
+
 # Additional links
  - [ARM userland utilities](https://github.com/jaredmcneill/userland)
 

fix typo
Index: wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn	5 Feb 2015 05:13:21 -0000	1.4
+++ wikisrc/users/msaitoh/Comparison_of_implementations_of_Ethernet_drivers.mdwn	5 Feb 2015 08:28:30 -0000	1.5
@@ -1,7 +1,7 @@
 <table class="center">
 <tr>
   <th>driver</th>
-  <th>where dmemem is allocated in</th>
+  <th>where dmamem is allocated in</th>
   <th>variations of mutex</th>
   <th>if_init lock</th>
   <th>if_start lock</th>

Add a comment