Recent changes to this wiki:

Note A80 basic framebuffer support
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- wikisrc/ports/evbarm/allwinner.mdwn	19 Dec 2014 00:13:09 -0000	1.44
+++ wikisrc/ports/evbarm/allwinner.mdwn	21 Dec 2014 23:08:18 -0000	1.45
@@ -36,10 +36,10 @@
    - OTG (A20)
  - SATA (A10/A20)
  - Gigabit Ethernet (GMAC)
- - HDMI (A20/A31)
-   - DDC / EDID mode detection
-   - Audio support
- - Framebuffer (A20/A31)
+ - HDMI
+   - DDC / EDID mode detection (A20/A31)
+   - Audio support (A20/A31)
+ - Framebuffer (A20/A31/A80)
  - IR receiver (A20/A31/A80)
 
 # TODO
@@ -56,7 +56,7 @@
    - big.LITTLE support
    - USB3 (OTG and XHCI)
    - IR transmitter
-   - HDMI
+   - HDMI (DDC and mode setting; currently relies on U-Boot for setup)
    - Audio codec
  - All
    - USB device mode

xref requirements from previous discussions. Probably worth merging.
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 08:13:33 -0000	1.14
+++ wikisrc/projects/project/cvs-migration.mdwn	19 Dec 2014 17:13:46 -0000	1.15
@@ -11,7 +11,8 @@
 
 description="""
 
-###background and description
+### Background and description
+
 NetBSD is one of the first projects to use internet-available source control.
 It has been using CVS since the very beginning of the project (over 21 years)
 and the repository is vast.
@@ -46,7 +47,6 @@
 has already been done, which is why we are able to now ask "how would the project
 continue to function?"
 
-
 ### Our decision matters
 
 You're reading this because you care about the future of NetBSD and
@@ -96,6 +96,10 @@
 What are some considerations you think are important? Are they
 listed here? If not, edit this page and add them.
 
+### Some previously collected considerations
+
+* [[mailing-lists/tech-repository]]
+
 ### Considerations
 
 Humans

update the conversion part, it was badly out of date
Index: wikisrc/mailing-lists/tech-repository.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/mailing-lists/tech-repository.mdwn,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- wikisrc/mailing-lists/tech-repository.mdwn	24 Dec 2010 10:33:44 -0000	1.16
+++ wikisrc/mailing-lists/tech-repository.mdwn	19 Dec 2014 12:59:12 -0000	1.17
@@ -149,74 +149,16 @@
 
 ***
 
-## Conversion experiences
+## Conversion 
+
+### fossil
+
+We have a successful conversion from cvs to fossil since ~mid 2011, mostly thanks to the work of Jörg Sonnenberger.
 
 ### git
 
-Conversion of all modules to git succeeded using fromcvs togit. The resulting git repository of src contains several errors where files have a wrong version (eg in hunt/Makefile the contents of the file on the vendor branch appear as tip of the master branch, which is quite wrong).
-There have been no reports of errors in the other modules; this may be due to a lack of testing.
+We have a successful conversion to git via the fossil conversion; also, probably now a successful direct conversion via the tools by Eric S. Raymond.
 
 ### hg
 
-Conversion of src failed. Afair the rest worked when using Mercurial 1.3.*. Alas, fromcvs tohg is not compatible with Mercurial 1.4 which is in pkgsrc now and is the version to use with Python 2.6 (afair). Two identified problems:
-<pre>
-        self.ui = ui.ui(interactive = False)
-</pre>
-wants to be
-<pre>
-        self.ui = ui.ui()
-        self.ui.setconfig('ui', 'interactive', 'off')
-</pre>
-in /usr/pkg/share/fromcvs/tohg.py line 10 (easily fixed, obviously)
-and
-<pre>
-        n = self.hgrepo.commit(files = files,
-                               text = text,
-                               user = user,
-                               date = "%s 0" % date,
-                               p1 = p1,
-                               p2 = p2,
-                               extra = {'branch': branch})
-</pre>
-needs to be replaces with something that works with the 1.4 commit that looks like this:
-<pre>
-    def commit(self, text="", user=None, date=None, match=None, force=False,
-               editor=False, extra={}):
-</pre>
-which is where I remembered that I wasn't planning to learn Python this week.
-
-Next try: hg convert on pkgsrc
-<pre>
---- /usr/pkg/lib/python2.6/site-packages/hgext/convert/cvsps.py 2009-12-02 01:30:45.000000000 +0000
-+++ /tmp/cvsps.py       2010-01-20 12:52:11.000000000 +0000
-@@ -271,14 +271,14 @@
-                 tags[rev].append(match.group(1))
-                 branchmap[match.group(1)] = match.group(2)
- 
--            elif re_31.match(line):
-+            elif re_31.match(line) and re_50.match(peek):
-                 state = 5
-             elif re_32.match(line):
-                 state = 0
- 
-         elif state == 4:
-             # expecting '------' separator before first revision
--            if re_31.match(line):
-+            if re_31.match(line) and re_50.match(peek):
-                 state = 5
-             else:
-                 assert not re_32.match(line), _('must have at least '
-@@ -357,7 +357,7 @@
- 
-         elif state == 8:
-             # store commit log message
--            if re_31.match(line):
-+            if re_31.match(line) and re_50.match(peek):
-                 state = 5
-                 store = True
-             elif re_32.match(line):
-</pre>
-helps it to cope with the output of cvs rlog -N -r1.66 pkgsrc/databases/rrdtool/Makefile (that's the easy one)
-but then it tries to parse the output of (eg) cvs rlog -N -r1.19 pkgsrc/graphics/dcraw/Makefile and it's not clear
-to me how it could hope to get that one right just from cvs rlog, and all alternatives are going to be rather tedious
-and I'm still not planning to learn Python this week. If you feel more energetic, feel free to hand over patches.
+A conversion to hg has also been done, ask agc@

VGA TODO
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- wikisrc/ports/evbarm/allwinner.mdwn	18 Dec 2014 02:40:55 -0000	1.43
+++ wikisrc/ports/evbarm/allwinner.mdwn	19 Dec 2014 00:13:09 -0000	1.44
@@ -63,6 +63,7 @@
    - SD/MMC UHS-I support (needs sdmmc(4) changes)
    - SDIO (Bluetooth / WiFi)
    - NAND
+   - VGA (Cubietruck, Hummingbird A31, Cubieboard4)
 
 # Installation
 

Added a comment: problems
--- /dev/null	2014-12-18 19:48:00.000000000 +0000
+++ wikisrc/ports/evbarm/allwinner/comment_2_c0e400c28df2838b74dbd0ff11d550cc._comment	2014-12-18 19:48:45.000000000 +0000
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmjiER5abAH1681xkJcWIoZhxB-3YNp0DM"
+ nickname="Gilles"
+ subject="problems"
+ date="2014-12-18T19:48:41Z"
+ content="""
+I succeeded to connect via the serial port, but I have a first problems, the root partition exceeds the maximum capacity of the partition:
+
+beagleboard# df -h
+Filesystem         Size       Used      Avail %Cap Mounted on
+/dev/ld0a          434M       434M       -21M 105% /
+
+I could make some changes and I do not know if it came from there, but it is impossible to create user the database is apparently corrupt:
+
+beagleboard# pwd_mkdb /etc/master.passwd 
+pwd_mkdb: Cannot open `/etc/spwd.db.tmp': File exists
+
+
+"""]]

Slides.
Index: wikisrc/users/alnsn.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/alnsn.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/users/alnsn.mdwn	18 Dec 2014 17:50:59 -0000	1.1
+++ wikisrc/users/alnsn.mdwn	18 Dec 2014 19:48:00 -0000	1.2
@@ -1,5 +1,5 @@
 # alnsn's netbsd-wiki page
 
 ## BPF JIT
-* [[JIT Code Generator for NetBSD|users/alnsn/EuroBSDCon2014-JIT-Code-Generator-for-NetBSD.pdf]]
+* Slides of my presentation at EuroBSDCon 2014 in Sofia: [[JIT Code Generator for NetBSD (pdf)|users/alnsn/EuroBSDCon2014-JIT-Code-Generator-for-NetBSD.pdf]]
 * [Project's external repo](https://github.com/alnsn/bpfjit)

Add my page and EuroBSDCon 2014 presentation.
--- /dev/null	2014-12-18 17:50:01.000000000 +0000
+++ wikisrc/users/alnsn.mdwn	2014-12-18 17:51:03.000000000 +0000
@@ -0,0 +1,5 @@
+# alnsn's netbsd-wiki page
+
+## BPF JIT
+* [[JIT Code Generator for NetBSD|users/alnsn/EuroBSDCon2014-JIT-Code-Generator-for-NetBSD.pdf]]
+* [Project's external repo](https://github.com/alnsn/bpfjit)

Added a comment: cubietruck vga/hdmi configuration
--- /dev/null	2014-12-18 15:10:00.000000000 +0000
+++ wikisrc/ports/evbarm/allwinner/comment_1_d020cb7524ce2af896db8534ce2c6200._comment	2014-12-18 15:15:33.000000000 +0000
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmjiER5abAH1681xkJcWIoZhxB-3YNp0DM"
+ nickname="Gilles"
+ subject="cubietruck vga/hdmi configuration"
+ date="2014-12-18T15:15:28Z"
+ content="""
+hello,
+in order to properly operate the cubietruck, I set up a fex/bin file to the root of my SD card. 
+I tried without the script, with a script modified to display on a VGA screen, as well as an original script for display on HDMI display, but none work. 
+I feel that the script is not even read it. 
+the LED display does not do properly. However, I checked several times, I put exactly what was stated in the wiki.
+"""]]

Added Tools under Considerations
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 08:10:00 -0000	1.13
+++ wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 08:13:33 -0000	1.14
@@ -124,5 +124,11 @@
 * Fix a commit message
 * Create a diff between two versions of a file
 
+Tools
+
+* Command line tool
+* Web based source code browsing and maybe riffing (in the style of e.g. trac)
+* Availability on different platforms (pkgsrc is not NetBSD only)
+
 """
 ]]

Added Workflow under Considerations
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 08:07:20 -0000	1.12
+++ wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 08:10:00 -0000	1.13
@@ -111,6 +111,18 @@
 * Some ports/machines are memory constraint or rather slow (by todays standards), a VCS different than CVS should be able to used on these machines as well.
  (e.g. git has parameters to tune memory usage, and there exists git-cvsserver which allows a git repository to be accessed using a CVS client)
 
+Workflow / Commonly used actions
+
+* Checkout the whole tree
+* Checkout a partial tree (or subdirectory)
+* Create a branch
+* Merge a branch with the head/main branch
+* Create a tag
+* Commit local changes to a branch
+* Commit local changes to the main branch
+* Revert a commit
+* Fix a commit message
+* Create a diff between two versions of a file
 
 """
 ]]

Machines section under Considerations
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 01:03:36 -0000	1.11
+++ wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 08:07:20 -0000	1.12
@@ -106,6 +106,10 @@
 * People who can commit directly to NetBSD
 * People who can't commit directly to NetBSD
 
+Machines
+
+* Some ports/machines are memory constraint or rather slow (by todays standards), a VCS different than CVS should be able to used on these machines as well.
+ (e.g. git has parameters to tune memory usage, and there exists git-cvsserver which allows a git repository to be accessed using a CVS client)
 
 
 """

minor tweaks to make what's happening slightly more clear.
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- wikisrc/ports/evbarm/allwinner.mdwn	8 Dec 2014 11:57:38 -0000	1.42
+++ wikisrc/ports/evbarm/allwinner.mdwn	18 Dec 2014 02:40:55 -0000	1.43
@@ -72,12 +72,12 @@
 * Download a U-Boot build for your board
   * A10/A20: Download from the linux-sunxi web site <http://dl.linux-sunxi.org/nightly/u-boot-sunxi/u-boot-sunxi/u-boot-sunxi-latest/>
   * A31: The standard u-boot-sunxi tree doesn't support A31 yet. Until sun6i support is merged, a build is available at <http://dis.invisible.ca/allwinner/a31/> 
-* Write the *u-boot-sunxi-with-spl.bin* loader to the base image:
+* Write the *u-boot-sunxi-with-spl.bin* loader to the empty space at the start of the base image:
 [[!template  id=programlisting text="""
 # dd if=u-boot-sunxi-with-spl.bin of=beagleboard.img bs=1k seek=8 conv=notrunc
 """]]
 * Write the image to an SD card.
-* Copy the kernel (netbsd.ub) for your board to the root of the MS-DOS partition.
+* Copy the kernel (netbsd.ub) for your board to the root of the MS-DOS partition on the SD card.
 * Create or edit uEnv.txt on the MS-DOS partition:
 [[!template  id=programlisting text="""
 bootargs=root=ld0a

+ security teams
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 01:00:08 -0000	1.10
+++ wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 01:03:36 -0000	1.11
@@ -102,6 +102,7 @@
 
 * People who administer Project resources
 * People who administer release branches
+* People who administer security updates
 * People who can commit directly to NetBSD
 * People who can't commit directly to NetBSD
 

- can not is two words
- add releng to People
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 00:57:59 -0000	1.9
+++ wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 01:00:08 -0000	1.10
@@ -77,7 +77,7 @@
 There is no available choice of VCS that entirely avoids tradeoffs
 for us. Therefore, to choose intelligently, we must first consider
 all the tradeoffs we can think of, then decide which ones we can
-live with and which we cannot.
+live with and which we can not.
 
 ### Our decision needs to be made together
 
@@ -101,6 +101,7 @@
 Humans
 
 * People who administer Project resources
+* People who administer release branches
 * People who can commit directly to NetBSD
 * People who can't commit directly to NetBSD
 

xref PR using the handy template.
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 09:52:59 -0000	1.12
+++ wikisrc/users/dholland/hgnb.mdwn	18 Dec 2014 00:58:55 -0000	1.13
@@ -369,7 +369,8 @@
 In CVS you can keep uncommitted changes in your tree indefinitely with
 no ill effects.
 (Or at least, no ill effects until you want to commit other changes to
-the same files, run into merge conflicts, or hit PR 42961.)
+the same files, run into merge conflicts, or hit [[!template id=pr
+number=42961]].)
 
 In Mercurial having uncommitted changes keeps you from doing explicit
 merges, which you need to do much more often than in CVS.

Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 00:52:43 -0000	1.8
+++ wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 00:57:59 -0000	1.9
@@ -21,7 +21,7 @@
 
 NetBSD also has various small internal repositories (like this wiki).
 
-During the last twenty years tooling has improved the popular developer culture
+During the last twenty years tooling has improved and popular developer culture
 has shifted to new workflows.
 
 The purpose of this project is to identify:

Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 00:45:51 -0000	1.7
+++ wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 00:52:43 -0000	1.8
@@ -10,17 +10,54 @@
 difficulty="hard"
 
 description="""
-# Our decision matters
+
+###background and description
+NetBSD is one of the first projects to use internet-available source control.
+It has been using CVS since the very beginning of the project (over 21 years)
+and the repository is vast.
+
+NetBSD also hosts the pkgsrc repository which has many small files, many
+"imports" and other technical challenges associated with VCS.
+
+NetBSD also has various small internal repositories (like this wiki).
+
+During the last twenty years tooling has improved the popular developer culture
+has shifted to new workflows.
+
+The purpose of this project is to identify:
+
+ * existing 'workflows' in common use among developers
+    * (example): [[dholland/hgnb]]
+ * existing 'tooling' within NetBSD the organization
+    * how much memory/disk is required to host NetBSD?
+    * how are backups performed?
+    * can the tools be cross-build?
+ * security requirements like
+    * how do we validate commits?
+    * how do we ensure commits originated from developers?
+ * release engineering requirements such as
+    * how does a pullup request work?
+    * how do we ensure the correct files are included in the correct release branches?
+    * how do we checkout a release branch
+    * how do we look at the history of a release branch
+    * how do we get different revisions of a file on a branch
+
+major parts of the technical work like "how to convert FROM CVS to git/hg/fossil"
+has already been done, which is why we are able to now ask "how would the project
+continue to function?"
+
+
+### Our decision matters
 
 You're reading this because you care about the future of NetBSD and
 you understand that good tools act as a force multiplier.
 
-# Our decision is not obvious
+### Our decision is not obvious
 
 If it were, we'd have made it already (and wouldn't be disagreeing
 so persistently about which one it needs to be ;-).
 
-# Our decision needs to be about the whole elephant
+### Our decision needs to be about the whole elephant
 
 We all understand the basics of using source control. This level
 of understanding is necessary but not sufficient to make an informed
@@ -42,7 +79,7 @@
 all the tradeoffs we can think of, then decide which ones we can
 live with and which we cannot.
 
-# Our decision needs to be made together
+### Our decision needs to be made together
 
 We're a community. The only way a complicated, interconnected set
 of changes like this can be implemented is for us to arrive at rough
@@ -54,56 +91,19 @@
 - is worth the effort to switch, and
 - has volunteers to do the work.
 
-# How you can help, right now
+### How you can help, right now
 
 What are some considerations you think are important? Are they
 listed here? If not, edit this page and add them.
 
-# Considerations
+### Considerations
 
-# Humans
+Humans
 
-## People who administer Project resources
+* People who administer Project resources
+* People who can commit directly to NetBSD
+* People who can't commit directly to NetBSD
 
-## People who can commit directly to NetBSD
-
-## People who can't commit directly to NetBSD
-
-# Other
-
-NetBSD is one of the first projects to use internet-available source control.
-It has been using CVS since the very beginning of the project (over 21 years)
-and the repository is vast.
-
-NetBSD also hosts the pkgsrc repository which has many small files, many
-"imports" and other technical challenges associated with VCS.
-
-NetBSD also has various small internal repositories (like this wiki).
-
-During the last twenty years tooling has improved the popular developer culture
-has shifted to new workflows.
-
-The purpose of this project is to identify:
-
- * existing 'workflows' in common use among developers
-    * (example): [[dholland/hgnb]]
- * existing 'tooling' within NetBSD the organization
-    * how much memory/disk is required to host NetBSD?
-    * how are backups performed?
-    * can the tools be cross-build?
- * security requirements like
-    * how do we validate commits?
-    * how do we ensure commits originated from developers?
- * release engineering requirements such as
-    * how does a pullup request work?
-    * how do we ensure the correct files are included in the correct release branches?
-    * how do we checkout a release branch
-    * how do we look at the history of a release branch
-    * how do we get different revisions of a file on a branch
-
-major parts of the technical work like "how to convert FROM CVS to git/hg/fossil"
-has already been done, which is why we are able to now ask "how would the project
-continue to function?"
 
 
 """

Provide some decision-making context. Invite help surveying the tradeoffs.
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/projects/project/cvs-migration.mdwn	17 Dec 2014 20:54:48 -0000	1.6
+++ wikisrc/projects/project/cvs-migration.mdwn	18 Dec 2014 00:45:51 -0000	1.7
@@ -10,6 +10,67 @@
 difficulty="hard"
 
 description="""
+# Our decision matters
+
+You're reading this because you care about the future of NetBSD and
+you understand that good tools act as a force multiplier.
+
+# Our decision is not obvious
+
+If it were, we'd have made it already (and wouldn't be disagreeing
+so persistently about which one it needs to be ;-).
+
+# Our decision needs to be about the whole elephant
+
+We all understand the basics of using source control. This level
+of understanding is necessary but not sufficient to make an informed
+decision about whether to migrate any or all of NetBSD's repositories
+to another VCS, and if so which, or how.
+
+Our choice of VCS carries implications not only about how developers
+hack on NetBSD, but also about how non-developers contribute and
+become developers, and how Project sysadmins keep our valuable code
+secure. Therefore, any choice of VCS other than the default (sticking
+with CVS for a while longer) necessarily implies that as a group,
+we all need to learn how we're going to do what we expect to need
+to do. Not all of this learning needs to happen before we can make
+a reasonably confident decision for our Project. But if we want to
+arrive at consensus, much of it does.
+
+There is no available choice of VCS that entirely avoids tradeoffs
+for us. Therefore, to choose intelligently, we must first consider
+all the tradeoffs we can think of, then decide which ones we can
+live with and which we cannot.
+
+# Our decision needs to be made together
+
+We're a community. The only way a complicated, interconnected set
+of changes like this can be implemented is for us to arrive at rough
+consensus that some particular VCS:
+
+- is sufficiently well suited to our project's needs in theory,
+- is sufficiently easily adapted to our needs in practice,
+- has a sufficiently fail-safe migration plan,
+- is worth the effort to switch, and
+- has volunteers to do the work.
+
+# How you can help, right now
+
+What are some considerations you think are important? Are they
+listed here? If not, edit this page and add them.
+
+# Considerations
+
+# Humans
+
+## People who administer Project resources
+
+## People who can commit directly to NetBSD
+
+## People who can't commit directly to NetBSD
+
+# Other
+
 NetBSD is one of the first projects to use internet-available source control.
 It has been using CVS since the very beginning of the project (over 21 years)
 and the repository is vast.
@@ -25,7 +86,7 @@
 The purpose of this project is to identify:
 
  * existing 'workflows' in common use among developers
-    * (example): [users/dholland/hgnb](/users/dholland/hgnb)
+    * (example): [[dholland/hgnb]]
  * existing 'tooling' within NetBSD the organization
     * how much memory/disk is required to host NetBSD?
     * how are backups performed?

Cross building seems to be important.
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/projects/project/cvs-migration.mdwn	15 Dec 2014 21:53:57 -0000	1.5
+++ wikisrc/projects/project/cvs-migration.mdwn	17 Dec 2014 20:54:48 -0000	1.6
@@ -29,6 +29,7 @@
  * existing 'tooling' within NetBSD the organization
     * how much memory/disk is required to host NetBSD?
     * how are backups performed?
+    * can the tools be cross-build?
  * security requirements like
     * how do we validate commits?
     * how do we ensure commits originated from developers?

Add section on LaTeX-Mk for managing/building LaTeX based projects.
Index: wikisrc/tutorials/latex_in_netbsd.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/latex_in_netbsd.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/tutorials/latex_in_netbsd.mdwn	13 Apr 2013 21:55:28 -0000	1.2
+++ wikisrc/tutorials/latex_in_netbsd.mdwn	17 Dec 2014 19:22:34 -0000	1.3
@@ -190,6 +190,31 @@
 commands will be called one after the other, and you don't have to care for the
 order afterwards anymore -- this is handled in the Makefile now.
 
+### LaTeX-Mk
+
+The latex-mk package in pkgsrc (print/latex-mk) provides a more comprehensive and capable
+build system for LaTeX based documents
+that is similar in spirit to the BSD make system used for building NetBSD.  As a simple example, 
+consider a document where the top level file is `mydoc.tex` and in turn, `ch1.tex`, `ch2.tex`, `ch3.tex`,
+and `refs.tex` are included.  In addition, a bibliography produced with BibTeX is in the file
+`mybib.bib`.  The `Makefile` for this project would be:
+
+    NAME= mydoc
+    TEXSRCS= ch1.tex ch2.tex ch3.tex refs.tex
+    BIBTEXSRCS= mybib.bib
+
+    .include "/usr/pkg/share/latex-mk/latex.mk" 
+
+The build system implemented by LaTeX-Mk provides various targets like view, pdf, viewpdf, etc.  
+For example
+
+   make viewpdf
+
+will take the steps needed to process the document, create a pdf file, and open a pdf viewer.
+
+For complete information on LaTeX-Mk's features and usage, visit 
+the [LaTeX-Mk homepage](http://latex-mk.sf.net).
+
 ### Version control systems
 
 When developing software, people often use

rename wiki/users/ozaki-r.mdwn to users/ozaki-r.mdwn
--- /dev/null	2014-12-17 13:00:00.000000000 +0000
+++ wikisrc/users/ozaki-r.mdwn	2014-12-17 13:02:38.000000000 +0000
@@ -0,0 +1,5 @@
+Ryota Ozaki (ozaki-r)
+
+## Work area
+* DTrace for ARM
+* MP-safe networking (Layer 2 and network device drivers)
--- wikisrc/wiki/users/ozaki-r.mdwn	2014-12-17 13:02:38.000000000 +0000
+++ /dev/null	2014-12-17 13:00:00.000000000 +0000
@@ -1,5 +0,0 @@
-Ryota Ozaki (ozaki-r)
-
-## Work area
-* DTrace for ARM
-* MP-safe networking (Layer 2 and network device drivers)

--- /dev/null	2014-12-17 12:50:00.000000000 +0000
+++ wikisrc/wiki/users/ozaki-r.mdwn	2014-12-17 12:50:16.000000000 +0000
@@ -0,0 +1,5 @@
+Ryota Ozaki (ozaki-r)
+
+## Work area
+* DTrace for ARM
+* MP-safe networking (Layer 2 and network device drivers)

Updates to better reflect the state of the RaspberryPi port.
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- wikisrc/ports/evbarm/raspberry_pi.mdwn	13 Sep 2014 08:09:37 -0000	1.22
+++ wikisrc/ports/evbarm/raspberry_pi.mdwn	17 Dec 2014 08:01:34 -0000	1.23
@@ -7,14 +7,15 @@
 <small>([Raspberry Pi image](http://www.flickr.com/photos/42325803@N07/8118758647/) by Christopher Lee used under CC-By-2.0 license)</small>
 
 # Installation
- - Use the latest HEAD/-current which builds for install
-   - As the Raspberry Pi port is still not part the stable release, you will want to use the
-     HEAD branch to download installation sets.
-   - You may use the rpi.img file created by an evbarm build - evbarm-earmv6hf is recommended, but this is not currently available on nyftp. For now, evbarm-earmhf is best.
-   - An example can be found in the 'evbarm-earmhf/binary/gzimg/' directory under releng.netbsd.org
-     - On nyftp.netbsd.org/pub/NetBSD-daily/HEAD/YYYYMMDDHHMMZ (it will look like pub/NetBSD-daily/HEAD/201305220150Z)
+ - 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 stable build will be under netbsd-7/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.
+   - <i>gunzip and dd</i> this img to your sd card.
 
 	   dd if=rpi.img of=/dev/disk1
 
@@ -86,16 +87,16 @@
 # What works in -current
  - multi-user boot with root on SD card
  - serial or graphics console (with EDID query / parsing)
- - Audio: works, but has issues. man page missing.
+ - DMA controller driver and sdhc(4) support
+ - Audio: works. man page missing.
  - I²C: works, could use enhancements, man page
  - GPIO
  - RNG
  - SPI: could use enhancements, man page
- - VCHIQ: man page missing. (-current)
+ - VCHIQ: man page missing.
  - USB (host) - dwctwo(4)
  - USB Ethernet - usmsc(4)
  - X windows.
 
 # What needs work
  - USB (host); isochronous transfers.
- - DMA controller driver and sdhc(4) support

- tyop
- more questions about branches
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/projects/project/cvs-migration.mdwn	15 Dec 2014 17:51:37 -0000	1.4
+++ wikisrc/projects/project/cvs-migration.mdwn	15 Dec 2014 21:53:57 -0000	1.5
@@ -28,13 +28,16 @@
     * (example): [users/dholland/hgnb](/users/dholland/hgnb)
  * existing 'tooling' within NetBSD the organization
     * how much memory/disk is required to host NetBSD?
-    * how are bacups performed?
+    * how are backups performed?
  * security requirements like
     * how do we validate commits?
     * how do we ensure commits originated from developers?
  * release engineering requirements such as
     * how does a pullup request work?
     * how do we ensure the correct files are included in the correct release branches?
+    * how do we checkout a release branch
+    * how do we look at the history of a release branch
+    * how do we get different revisions of a file on a branch
 
 major parts of the technical work like "how to convert FROM CVS to git/hg/fossil"
 has already been done, which is why we are able to now ask "how would the project

Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/projects/project/cvs-migration.mdwn	15 Dec 2014 17:48:39 -0000	1.3
+++ wikisrc/projects/project/cvs-migration.mdwn	15 Dec 2014 17:51:37 -0000	1.4
@@ -25,16 +25,16 @@
 The purpose of this project is to identify:
 
  * existing 'workflows' in common use among developers
- ** (example): [users/dholland/hgnb](/users/dholland/hgnb)
+    * (example): [users/dholland/hgnb](/users/dholland/hgnb)
  * existing 'tooling' within NetBSD the organization
- ** how much memory/disk is required to host NetBSD/
- ** how are bacups performed?
+    * how much memory/disk is required to host NetBSD?
+    * how are bacups performed?
  * security requirements like
- ** how do we validate commits?
- ** how do we ensure commits originated from developers?
+    * how do we validate commits?
+    * how do we ensure commits originated from developers?
  * release engineering requirements such as
- ** how does a pullup request work?
- ** how do we ensure the correct files are included in the correct release branches?
+    * how does a pullup request work?
+    * how do we ensure the correct files are included in the correct release branches?
 
 major parts of the technical work like "how to convert FROM CVS to git/hg/fossil"
 has already been done, which is why we are able to now ask "how would the project

formatting take 2
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/projects/project/cvs-migration.mdwn	15 Dec 2014 17:48:00 -0000	1.2
+++ wikisrc/projects/project/cvs-migration.mdwn	15 Dec 2014 17:48:39 -0000	1.3
@@ -23,6 +23,7 @@
 has shifted to new workflows.
 
 The purpose of this project is to identify:
+
  * existing 'workflows' in common use among developers
  ** (example): [users/dholland/hgnb](/users/dholland/hgnb)
  * existing 'tooling' within NetBSD the organization

formatting take 1
Index: wikisrc/projects/project/cvs-migration.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/projects/project/cvs-migration.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/projects/project/cvs-migration.mdwn	15 Dec 2014 17:27:43 -0000	1.1
+++ wikisrc/projects/project/cvs-migration.mdwn	15 Dec 2014 17:48:00 -0000	1.2
@@ -23,17 +23,17 @@
 has shifted to new workflows.
 
 The purpose of this project is to identify:
-* existing 'workflows' in common use among developers
-** (example): [users/dholland/hgnb]
-* existing 'tooling' within NetBSD the organization
-** how much memory/disk is required to host NetBSD/
-** how are bacups performed?
-* security requirements like
-** how do we validate commits?
-** how do we ensure commits originated from developers?
-* release engineering requirements such as
-** how does a pullup request work?
-** how do we ensure the correct files are included in the correct release branches?
+ * existing 'workflows' in common use among developers
+ ** (example): [users/dholland/hgnb](/users/dholland/hgnb)
+ * existing 'tooling' within NetBSD the organization
+ ** how much memory/disk is required to host NetBSD/
+ ** how are bacups performed?
+ * security requirements like
+ ** how do we validate commits?
+ ** how do we ensure commits originated from developers?
+ * release engineering requirements such as
+ ** how does a pullup request work?
+ ** how do we ensure the correct files are included in the correct release branches?
 
 major parts of the technical work like "how to convert FROM CVS to git/hg/fossil"
 has already been done, which is why we are able to now ask "how would the project

add a cvs migration project page
--- /dev/null	2014-12-15 17:20:00.000000000 +0000
+++ wikisrc/projects/project/cvs-migration.mdwn	2014-12-15 17:27:46.000000000 +0000
@@ -0,0 +1,44 @@
+[[!template id=project
+
+title="CVS Migration for NetBSD repos"
+
+contact="""
+[tech-repository](mailto:tech-repository@netbsd.org)
+"""
+
+category="misc"
+difficulty="hard"
+
+description="""
+NetBSD is one of the first projects to use internet-available source control.
+It has been using CVS since the very beginning of the project (over 21 years)
+and the repository is vast.
+
+NetBSD also hosts the pkgsrc repository which has many small files, many
+"imports" and other technical challenges associated with VCS.
+
+NetBSD also has various small internal repositories (like this wiki).
+
+During the last twenty years tooling has improved the popular developer culture
+has shifted to new workflows.
+
+The purpose of this project is to identify:
+* existing 'workflows' in common use among developers
+** (example): [users/dholland/hgnb]
+* existing 'tooling' within NetBSD the organization
+** how much memory/disk is required to host NetBSD/
+** how are bacups performed?
+* security requirements like
+** how do we validate commits?
+** how do we ensure commits originated from developers?
+* release engineering requirements such as
+** how does a pullup request work?
+** how do we ensure the correct files are included in the correct release branches?
+
+major parts of the technical work like "how to convert FROM CVS to git/hg/fossil"
+has already been done, which is why we are able to now ask "how would the project
+continue to function?"
+
+
+"""
+]]

strip comment about cgd
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- wikisrc/users/mlelstv/using-large-disks.mdwn	8 Dec 2014 14:16:08 -0000	1.25
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	14 Dec 2014 10:26:36 -0000	1.26
@@ -305,8 +305,6 @@
    ccdconfig: NAME=hugedisk1: No such file or directory
 </code></pre>
 
-The cgd driver has a similar problem.
-
 ## configuring
 For now we use the wedge device directly.
 <pre><code>

failfail
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 09:51:06 -0000	1.11
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 09:52:59 -0000	1.12
@@ -65,6 +65,7 @@
 push.
 
 In the simple case, you do an explicit merge as follows:
+
                                         hg pull
                                         hg merge
                                         hg commit
@@ -72,9 +73,11 @@
 When you get a merge conflict, you first need to resolve it (in the
 usual way by editing) and then you must tag it resolved in hg before
 hg will let you commit, like this:
+
                                         hg resolve -m file
 
 You can list unresolved conflicts thus:
+
                                         hg resolve -l
 
 Note that even with the explicit merge this is almost exactly
@@ -86,6 +89,7 @@
 There is one gotcha, which is that you can't do explicit merges in a
 tree with uncommitted changes. The best way around this is to stash
 your changes:
+
                                         hg stash
                                         hg merge
                                         ...whatever merge stuff...
@@ -122,6 +126,7 @@
 A commit with no descendents (that is, the most recent commit on any
 line of development) is called a "head".
 You can list these as follows:
+
                                         hg heads
 
 This will include commits that have descendents only on other
@@ -134,10 +139,12 @@
 
 If you interrupt Mercurial (or Mercurial gets interrupted, e.g. by a
 system crash) you want to do this afterwards:
+
                                         hg recover
 
 and if you have reason to think the repository might be corrupt you
 can check it like this:
+
                                         hg verify
 
 ### Development branches
@@ -173,11 +180,13 @@
 instead and not something you need to be concerned about.
 
 Check out a new tree on a branch:
+
     cvs co -P -rlibc13                  hg clone [url]
                                         cd src
                                         hg update -r libc13
 
 Switch to a new tree on a branch:
+
     cvs up -dP -A -rlibc13              hg pull                         (if needed)
                                         hg update -r libc13
 
@@ -185,6 +194,7 @@
 crossing from one branch to another because it doesn't know how to
 merge them.
 In that case do this:
+
                                         hg update -r libc13-base
                                         [resolve conflicts if needed]
                                         hg update -r libc13
@@ -403,8 +413,10 @@
 sorted out.
 
 To revert to a specific version:
+
                                         hg revert -r rev subtree
 To revert to a specific date:
+
                                         hg revert -d date subtree
 
 

fix more markup fail
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 03:15:45 -0000	1.10
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 09:51:06 -0000	1.11
@@ -195,6 +195,7 @@
     cat CVS/Tag                         hg branch
 
 See list of branches:
+
     [no can do reliably]                hg branches     
 
 Note that unlike with CVS there's no version-control-related reason to

hurray for semantic whitespace
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 03:03:23 -0000	1.9
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 03:15:45 -0000	1.10
@@ -26,22 +26,22 @@
 
 Therefore, the basic usage is almost entirely unchanged:
 
-    CVS                         Mercurial
+    CVS                                 Mercurial
 
-    cvs checkout                hg clone
-    cvs update -dP              hg pull && hg update
-    cvs -n update               hg status
-    cvs log file                hg log file  [or just hg log]
-
-    cvs update -p file          hg cat file
-    cvs annotate                hg annotate
-    cvs diff -u                 hg diff
-    cvs add                     hg add
-    cvs rm                      hg rm
-    [no can do]                 hg cp
-    [no can do]                 hg mv
-    cvs commit                  hg commit && hg push
-    cvs tag                     hg tag
+    cvs checkout                        hg clone
+    cvs update -dP                      hg pull && hg update
+    cvs -n update                       hg status
+    cvs log file                        hg log file  [or just hg log]
+
+    cvs update -p file                  hg cat file
+    cvs annotate                        hg annotate
+    cvs diff -u                         hg diff
+    cvs add                             hg add
+    cvs rm                              hg rm
+    [no can do]                         hg cp
+    [no can do]                         hg mv
+    cvs commit                          hg commit && hg push
+    cvs tag                             hg tag
 
 You will notice that CVS's update and commit have been divided into
 two now-separable actions: in Mercurial, pull fetches changes from a
@@ -65,17 +65,17 @@
 push.
 
 In the simple case, you do an explicit merge as follows:
-				hg pull
-				hg merge
-				hg commit
+                                        hg pull
+                                        hg merge
+                                        hg commit
 
 When you get a merge conflict, you first need to resolve it (in the
 usual way by editing) and then you must tag it resolved in hg before
 hg will let you commit, like this:
-				hg resolve -m file
+                                        hg resolve -m file
 
 You can list unresolved conflicts thus:
-				hg resolve -l
+                                        hg resolve -l
 
 Note that even with the explicit merge this is almost exactly
 equivalent to the CVS behavior when someone commits ahead of you.
@@ -86,10 +86,10 @@
 There is one gotcha, which is that you can't do explicit merges in a
 tree with uncommitted changes. The best way around this is to stash
 your changes:
-				hg stash
-				hg merge
-				...whatever merge stuff...
-				hg unstash
+                                        hg stash
+                                        hg merge
+                                        ...whatever merge stuff...
+                                        hg unstash
 
 You can also do the merge in another tree; because Mercurial is a
 distributed tool, you can create a temporary copy of your tree, or
@@ -99,14 +99,14 @@
 in "scratch" so it can be used for this kind of thing. Then you can do
 the following (starting at the top of src):
 
-				hg push ../scratch
-				cd ../scratch
-				hg update
-				hg merge
-				...whatever merge stuff, including commit...
-				cd ../src
-				hg pull ../scratch
-				hg update
+                                        hg push ../scratch
+                                        cd ../scratch
+                                        hg update
+                                        hg merge
+                                        ...whatever merge stuff, including commit...
+                                        cd ../src
+                                        hg pull ../scratch
+                                        hg update
 
 ### Disconnected operation
 
@@ -122,7 +122,7 @@
 A commit with no descendents (that is, the most recent commit on any
 line of development) is called a "head".
 You can list these as follows:
-				hg heads
+                                        hg heads
 
 This will include commits that have descendents only on other
 branches, e.g. the last commit on a development branch that's been
@@ -134,11 +134,11 @@
 
 If you interrupt Mercurial (or Mercurial gets interrupted, e.g. by a
 system crash) you want to do this afterwards:
-				hg recover
+                                        hg recover
 
 and if you have reason to think the repository might be corrupt you
 can check it like this:
-				hg verify
+                                        hg verify
 
 ### Development branches
 
@@ -159,43 +159,43 @@
 
 Create a new branch:
 
-	cvs update -dP		hg pull && hg update    (if needed)
-	update doc/BRANCHES	update doc/BRANCHES     (if appropriate)
-	cvs commit doc/BRANCHES	hg commit doc/BRANCHES  (if needed)
-	cvs tag libc13-base	hg tag libc13-base
-	cvs ph'tagn		hg branch libc13
-	[make first change]	[make first change]
-	cvs commit		hg commit
-				hg push
+    cvs update -dP                      hg pull && hg update            (if needed)
+    update doc/BRANCHES                 update doc/BRANCHES             (if appropriate)
+    cvs commit doc/BRANCHES             hg commit doc/BRANCHES          (if needed)
+    cvs tag libc13-base                 hg tag libc13-base
+    cvs ph'tagn                         hg branch libc13
+    [make first change]                 [make first change]
+    cvs commit                          hg commit
+                                        hg push
 
 Mercurial warns you that branches are permanent and expensive; this
 warning is aimed at git users who ought to be creating bookmarks
 instead and not something you need to be concerned about.
 
 Check out a new tree on a branch:
-	cvs co -P -rlibc13	hg clone [url]
-				cd src
-				hg update -r libc13
+    cvs co -P -rlibc13                  hg clone [url]
+                                        cd src
+                                        hg update -r libc13
 
 Switch to a new tree on a branch:
-	cvs up -dP -A -rlibc13	hg pull			(if needed)
-				hg update -r libc13
+    cvs up -dP -A -rlibc13              hg pull                         (if needed)
+                                        hg update -r libc13
 
 Note that if you have uncommitted changes, Mercurial will balk at
 crossing from one branch to another because it doesn't know how to
 merge them.
 In that case do this:
-				hg update -r libc13-base
-				[resolve conflicts if needed]
-				hg update -r libc13
-				[resolve conflicts if needed]
+                                        hg update -r libc13-base
+                                        [resolve conflicts if needed]
+                                        hg update -r libc13
+                                        [resolve conflicts if needed]
 
 Check which branch you're currently on:
 
-	cat CVS/Tag		hg branch
+    cat CVS/Tag                         hg branch
 
 See list of branches:
-	[no can do reliably]	hg branches	
+    [no can do reliably]                hg branches     
 
 Note that unlike with CVS there's no version-control-related reason to
 get a new tree just to work on a branch.
@@ -206,17 +206,17 @@
 
 Sync your branch with the trunk ("HEAD" in CVS):
 
-	cvs ph'tagn		hg merge default
-	[resolve conflicts]	[resolve conflicts]
-	cvs commit		hg commit

(Diff truncated)
hurray for semantic whitespace
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 03:02:37 -0000	1.8
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 03:03:23 -0000	1.9
@@ -26,22 +26,22 @@
 
 Therefore, the basic usage is almost entirely unchanged:
 
-    CVS				Mercurial
+    CVS                         Mercurial
 
-    cvs checkout			hg clone
-    cvs update -dP			hg pull && hg update
-    cvs -n update			hg status
-    cvs log file			hg log file  [or just hg log]
-
-    cvs update -p file		hg cat file
-    cvs annotate			hg annotate
-    cvs diff -u			hg diff
-    cvs add			hg add
-    cvs rm				hg rm
-    [no can do]			hg cp
-    [no can do]			hg mv
-    cvs commit			hg commit && hg push
-    cvs tag			hg tag
+    cvs checkout                hg clone
+    cvs update -dP              hg pull && hg update
+    cvs -n update               hg status
+    cvs log file                hg log file  [or just hg log]
+
+    cvs update -p file          hg cat file
+    cvs annotate                hg annotate
+    cvs diff -u                 hg diff
+    cvs add                     hg add
+    cvs rm                      hg rm
+    [no can do]                 hg cp
+    [no can do]                 hg mv
+    cvs commit                  hg commit && hg push
+    cvs tag                     hg tag
 
 You will notice that CVS's update and commit have been divided into
 two now-separable actions: in Mercurial, pull fetches changes from a

fail.fail.fail
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 03:01:49 -0000	1.7
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 03:02:37 -0000	1.8
@@ -26,22 +26,22 @@
 
 Therefore, the basic usage is almost entirely unchanged:
 
-   CVS				Mercurial
+    CVS				Mercurial
 
-   cvs checkout			hg clone
-   cvs update -dP			hg pull && hg update
-   cvs -n update			hg status
-   cvs log file			hg log file  [or just hg log]
-
-   cvs update -p file		hg cat file
-   cvs annotate			hg annotate
-   cvs diff -u			hg diff
-   cvs add			hg add
-   cvs rm				hg rm
-   [no can do]			hg cp
-   [no can do]			hg mv
-   cvs commit			hg commit && hg push
-   cvs tag			hg tag
+    cvs checkout			hg clone
+    cvs update -dP			hg pull && hg update
+    cvs -n update			hg status
+    cvs log file			hg log file  [or just hg log]
+
+    cvs update -p file		hg cat file
+    cvs annotate			hg annotate
+    cvs diff -u			hg diff
+    cvs add			hg add
+    cvs rm				hg rm
+    [no can do]			hg cp
+    [no can do]			hg mv
+    cvs commit			hg commit && hg push
+    cvs tag			hg tag
 
 You will notice that CVS's update and commit have been divided into
 two now-separable actions: in Mercurial, pull fetches changes from a

fail.fail.fail
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 03:01:20 -0000	1.6
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 03:01:49 -0000	1.7
@@ -26,22 +26,22 @@
 
 Therefore, the basic usage is almost entirely unchanged:
 
-  CVS				Mercurial
+   CVS				Mercurial
 
-  cvs checkout			hg clone
-  cvs update -dP			hg pull && hg update
-  cvs -n update			hg status
-  cvs log file			hg log file  [or just hg log]
-
-  cvs update -p file		hg cat file
-  cvs annotate			hg annotate
-  cvs diff -u			hg diff
-  cvs add			hg add
-  cvs rm				hg rm
-  [no can do]			hg cp
-  [no can do]			hg mv
-  cvs commit			hg commit && hg push
-  cvs tag			hg tag
+   cvs checkout			hg clone
+   cvs update -dP			hg pull && hg update
+   cvs -n update			hg status
+   cvs log file			hg log file  [or just hg log]
+
+   cvs update -p file		hg cat file
+   cvs annotate			hg annotate
+   cvs diff -u			hg diff
+   cvs add			hg add
+   cvs rm				hg rm
+   [no can do]			hg cp
+   [no can do]			hg mv
+   cvs commit			hg commit && hg push
+   cvs tag			hg tag
 
 You will notice that CVS's update and commit have been divided into
 two now-separable actions: in Mercurial, pull fetches changes from a

failfail
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 02:59:39 -0000	1.5
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 03:01:20 -0000	1.6
@@ -26,22 +26,22 @@
 
 Therefore, the basic usage is almost entirely unchanged:
 
- CVS				Mercurial
+  CVS				Mercurial
 
- cvs checkout			hg clone
- cvs update -dP			hg pull && hg update
- cvs -n update			hg status
- cvs log file			hg log file  [or just hg log]
-
- cvs update -p file		hg cat file
- cvs annotate			hg annotate
- cvs diff -u			hg diff
- cvs add			hg add
- cvs rm				hg rm
- [no can do]			hg cp
- [no can do]			hg mv
- cvs commit			hg commit && hg push
- cvs tag			hg tag
+  cvs checkout			hg clone
+  cvs update -dP			hg pull && hg update
+  cvs -n update			hg status
+  cvs log file			hg log file  [or just hg log]
+
+  cvs update -p file		hg cat file
+  cvs annotate			hg annotate
+  cvs diff -u			hg diff
+  cvs add			hg add
+  cvs rm				hg rm
+  [no can do]			hg cp
+  [no can do]			hg mv
+  cvs commit			hg commit && hg push
+  cvs tag			hg tag
 
 You will notice that CVS's update and commit have been divided into
 two now-separable actions: in Mercurial, pull fetches changes from a

fail
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 02:57:24 -0000	1.4
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 02:59:39 -0000	1.5
@@ -26,22 +26,22 @@
 
 Therefore, the basic usage is almost entirely unchanged:
 
-|	CVS			| Mercurial
+ CVS				Mercurial
 
- |	cvs checkout		| hg clone
- |	cvs update -dP		| hg pull && hg update
- |	cvs -n update		| hg status
- |	cvs log file		| hg log file  [or just hg log]
-
-	cvs update -p file	hg cat file
-	cvs annotate		hg annotate
-	cvs diff -u		hg diff
-	cvs add			hg add
-	cvs rm			hg rm
-	[no can do]		hg cp
-	[no can do]		hg mv
-	cvs commit		hg commit && hg push
-	cvs tag			hg tag
+ cvs checkout			hg clone
+ cvs update -dP			hg pull && hg update
+ cvs -n update			hg status
+ cvs log file			hg log file  [or just hg log]
+
+ cvs update -p file		hg cat file
+ cvs annotate			hg annotate
+ cvs diff -u			hg diff
+ cvs add			hg add
+ cvs rm				hg rm
+ [no can do]			hg cp
+ [no can do]			hg mv
+ cvs commit			hg commit && hg push
+ cvs tag			hg tag
 
 You will notice that CVS's update and commit have been divided into
 two now-separable actions: in Mercurial, pull fetches changes from a

nope
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 02:56:48 -0000	1.3
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 02:57:24 -0000	1.4
@@ -28,10 +28,10 @@
 
 |	CVS			| Mercurial
 
-|	cvs checkout		| hg clone
-|	cvs update -dP		| hg pull && hg update
-|	cvs -n update		| hg status
-|	cvs log file		| hg log file  [or just hg log]
+ |	cvs checkout		| hg clone
+ |	cvs update -dP		| hg pull && hg update
+ |	cvs -n update		| hg status
+ |	cvs log file		| hg log file  [or just hg log]
 
 	cvs update -p file	hg cat file
 	cvs annotate		hg annotate

that didn't work, try something else
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 02:56:04 -0000	1.2
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 02:56:48 -0000	1.3
@@ -26,12 +26,13 @@
 
 Therefore, the basic usage is almost entirely unchanged:
 
-	CVS			| Mercurial
+|	CVS			| Mercurial
+
+|	cvs checkout		| hg clone
+|	cvs update -dP		| hg pull && hg update
+|	cvs -n update		| hg status
+|	cvs log file		| hg log file  [or just hg log]
 
-	cvs checkout		| hg clone
-	cvs update -dP		| hg pull && hg update
-	cvs -n update		| hg status
-	cvs log file		| hg log file  [or just hg log]
 	cvs update -p file	hg cat file
 	cvs annotate		hg annotate
 	cvs diff -u		hg diff

test markup
Index: wikisrc/users/dholland/hgnb.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/dholland/hgnb.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 02:51:25 -0000	1.1
+++ wikisrc/users/dholland/hgnb.mdwn	14 Dec 2014 02:56:04 -0000	1.2
@@ -26,12 +26,12 @@
 
 Therefore, the basic usage is almost entirely unchanged:
 
-	CVS			Mercurial
+	CVS			| Mercurial
 
-	cvs checkout		hg clone
-	cvs update -dP		hg pull && hg update
-	cvs -n update		hg status
-	cvs log file		hg log file  [or just hg log]
+	cvs checkout		| hg clone
+	cvs update -dP		| hg pull && hg update
+	cvs -n update		| hg status
+	cvs log file		| hg log file  [or just hg log]
 	cvs update -p file	hg cat file
 	cvs annotate		hg annotate
 	cvs diff -u		hg diff

notes on using hg with netbsd if we switch
--- /dev/null	2014-12-14 02:50:01.000000000 +0000
+++ wikisrc/users/dholland/hgnb.mdwn	2014-12-14 02:51:28.000000000 +0000
@@ -0,0 +1,414 @@
+## Mercurial usage for NetBSD
+(hypothetically assuming the repositories have been converted)
+
+Here are some directions for how one would use Mercurial after a
+NetBSD transition from CVS to Mercurial.
+Most of this is pretty trivial (especially for anyone who's used
+Mercurial before...)
+
+There is a lot of FUD circulating about using a distributed version
+control system, what with talk of "workflows" and "topic branches" and
+other unfamiliar terms.
+Most of this arises from git user communities and git advocates;
+because git is screwy, using git is more complicated than using other
+better designed tools.
+Also, those suffering from Stockholm syndrome with respect to git tend
+to believe that the complexities of git are inherent to distributed
+version control, which is not the case; and many other people have been
+alarmed (or scared, or confused) by things such people have told them.
+
+### Basic usage
+
+First, NetBSD will go on using a central master repository. There is
+nothing to be gained by changing this; we have the project
+infrastructure to support it, and ultimately there has to be some tree
+somewhere that constitutes the master copy regardless.
+
+Therefore, the basic usage is almost entirely unchanged:
+
+	CVS			Mercurial
+
+	cvs checkout		hg clone
+	cvs update -dP		hg pull && hg update
+	cvs -n update		hg status
+	cvs log file		hg log file  [or just hg log]
+	cvs update -p file	hg cat file
+	cvs annotate		hg annotate
+	cvs diff -u		hg diff
+	cvs add			hg add
+	cvs rm			hg rm
+	[no can do]		hg cp
+	[no can do]		hg mv
+	cvs commit		hg commit && hg push
+	cvs tag			hg tag
+
+You will notice that CVS's update and commit have been divided into
+two now-separable actions: in Mercurial, pull fetches changes from a
+remote repository but doesn't affect your working tree, and update
+updates your working tree to (by default) the latest new changes.
+Similarly, commit integrates changes from your working tree, but
+locally only; push publishes those changes to the remote repository.
+
+This means that you can commit many times before pushing; this is
+often desirable if you're working on something nontrivial and you want
+to wait until it's ready before shipping it out.
+
+There is one catch, which is that other people can commit (and push to
+the master repository) while you're working. You can mostly avoid
+this, if you haven't committed anything locally yet, by doing "hg pull
+&& hg update" before committing, which will merge into your
+uncommitted changes and works exactly like updating before committing
+in CVS. However, if you've committed a number of changes, or someone
+got a new change in right between when you last pulled and when you
+committed, you need to do an explicit merge instead, and then you can
+push.
+
+In the simple case, you do an explicit merge as follows:
+				hg pull
+				hg merge
+				hg commit
+
+When you get a merge conflict, you first need to resolve it (in the
+usual way by editing) and then you must tag it resolved in hg before
+hg will let you commit, like this:
+				hg resolve -m file
+
+You can list unresolved conflicts thus:
+				hg resolve -l
+
+Note that even with the explicit merge this is almost exactly
+equivalent to the CVS behavior when someone commits ahead of you.
+The chief difference is that because Mercurial does whole-tree
+commits, *any* change ahead of you needs to be merged, not just one
+that touches the same files you've edited.
+
+There is one gotcha, which is that you can't do explicit merges in a
+tree with uncommitted changes. The best way around this is to stash
+your changes:
+				hg stash
+				hg merge
+				...whatever merge stuff...
+				hg unstash
+
+You can also do the merge in another tree; because Mercurial is a
+distributed tool, you can create a temporary copy of your tree, or
+push the changes you need to another tree you already have, do the
+work there, and push the results back. Let's suppose you have two
+trees, "src" and "scratch", where you never keep uncommitted changes
+in "scratch" so it can be used for this kind of thing. Then you can do
+the following (starting at the top of src):
+
+				hg push ../scratch
+				cd ../scratch
+				hg update
+				hg merge
+				...whatever merge stuff, including commit...
+				cd ../src
+				hg pull ../scratch
+				hg update
+
+### Disconnected operation
+
+Mercurial is a distributed system, and works by cloning the entire
+history into each tree you create.
+This has its downsides; but it means that you get disconnected
+operation for free.
+The only operations that need to contact the master repository are
+push, pull, incoming, and outgoing.
+
+### Some other bits
+
+A commit with no descendents (that is, the most recent commit on any
+line of development) is called a "head".
+You can list these as follows:
+				hg heads
+
+This will include commits that have descendents only on other
+branches, e.g. the last commit on a development branch that's been
+merged but not closed. Use "-t" ("topological heads") to hide these.
+
+You can see what "hg pull" and "hg push" are going to do via "hg
+incoming" and "hg outgoing" respectively.
+(FWIW, git can't do this.)
+
+If you interrupt Mercurial (or Mercurial gets interrupted, e.g. by a
+system crash) you want to do this afterwards:
+				hg recover
+
+and if you have reason to think the repository might be corrupt you
+can check it like this:
+				hg verify
+
+### Development branches
+
+A development branch is one where you're working on some new feature
+and you expect to merge the branch into the trunk later.
+Unlike in CVS, this is very cheap in Mercurial.
+The following are the operations you need, using "libc13" as an
+example branch name.
+
+Note that even if you're working on something nontrivial that will
+take a number of commits, if you aren't intending to push the changes
+out before they're done you don't need to make a branch and there's
+nothing gained by doing so.
+However, if you expect to be working over a long period of time on a
+major effort (such as the mythical libc version bump), and/or you
+want or expect other developers to contribute or at least test your
+changes before they're done, go ahead and create a branch.
+
+Create a new branch:
+
+	cvs update -dP		hg pull && hg update    (if needed)
+	update doc/BRANCHES	update doc/BRANCHES     (if appropriate)
+	cvs commit doc/BRANCHES	hg commit doc/BRANCHES  (if needed)
+	cvs tag libc13-base	hg tag libc13-base
+	cvs ph'tagn		hg branch libc13
+	[make first change]	[make first change]
+	cvs commit		hg commit
+				hg push
+
+Mercurial warns you that branches are permanent and expensive; this
+warning is aimed at git users who ought to be creating bookmarks
+instead and not something you need to be concerned about.
+
+Check out a new tree on a branch:
+	cvs co -P -rlibc13	hg clone [url]
+				cd src
+				hg update -r libc13
+
+Switch to a new tree on a branch:
+	cvs up -dP -A -rlibc13	hg pull			(if needed)
+				hg update -r libc13
+
+Note that if you have uncommitted changes, Mercurial will balk at
+crossing from one branch to another because it doesn't know how to
+merge them.
+In that case do this:
+				hg update -r libc13-base
+				[resolve conflicts if needed]
+				hg update -r libc13
+				[resolve conflicts if needed]
+
+Check which branch you're currently on:
+
+	cat CVS/Tag		hg branch
+
+See list of branches:
+	[no can do reliably]	hg branches	

(Diff truncated)
xref requester, previous request, what little upstream discussion I can find
Index: wikisrc/wiki/todo/make_toc_anchor_urls_permanent.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/wiki/todo/make_toc_anchor_urls_permanent.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/wiki/todo/make_toc_anchor_urls_permanent.mdwn	8 Dec 2014 14:04:42 -0000	1.2
+++ wikisrc/wiki/todo/make_toc_anchor_urls_permanent.mdwn	8 Dec 2014 14:21:52 -0000	1.3
@@ -1,3 +1,9 @@
 [[!meta title="make toc anchor URLs permanent"]]
 
-Currently anchors are named in section order, e.g. #index1h2. It would be nice if the anchor names were not volatile, so external links could reference a specific page section.
+Currently anchors are named in section order, e.g. `#index1h2`. It
+would be nice if the anchor names were not volatile, so external
+links could reference a specific page section. --[[jmcneill]]
+
+> I'm quite sure I remember this getting some design discussion
+> upstream. [[!iki todo/toc-with-human-readable-anchors]] is all
+> I'm finding at the moment, though. --[[schmonz]]
Index: wikisrc/wiki/todo/unformatted.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/wiki/todo/unformatted.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/wiki/todo/unformatted.mdwn	15 Jul 2013 15:33:52 -0000	1.8
+++ wikisrc/wiki/todo/unformatted.mdwn	8 Dec 2014 14:21:52 -0000	1.9
@@ -3,7 +3,7 @@
 * `jdf`'s top 3 (XXX inline these from `schmonz`'s notes)
 * When I want to link the `wsdisplay` subsection, I have to use the
   anchor `#index1h3`. Is it possible (as with file name normalisation)
-  to link `#wsdisplay` instead?
+  to link `#wsdisplay` instead? (see [[make toc anchor urls permanent]])
 * enable the TOC by default on every wiki page, e.g., three levels
   deep? Maybe also with a macro to disable it.
 * people think they should use capital letters to title a page, but

reformat
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- wikisrc/users/mlelstv/using-large-disks.mdwn	7 Dec 2014 11:01:24 -0000	1.24
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	8 Dec 2014 14:16:08 -0000	1.25
@@ -560,11 +560,13 @@
     /dev/rwd2d vg0  lvm2 a-   2.00t 2.00t
 </code></pre>
 
-This shows a problem with large disks, the LVM tools only understand conventional disk partitions
-that are limited to 2TB each. However, neither LVM, the device mapper driver or the disk drivers
-when using the raw partition are bound to the disklabel information. But you need to tell LVM
-the real size to override the synthesized disklabel. The real size is 11721045168 sectors
-by 512 bytes giving 5723166 Megabytes.
+This shows a problem with large disks, the LVM tools only understand
+conventional disk partitions that are limited to 2TB each. However,
+neither LVM, the device mapper driver nor the disk drivers when
+using the raw partition are bound to the disklabel information.
+But you need to tell LVM the real size to override the synthesized
+disklabel. The real size is 11721045168 sectors by 512 bytes giving
+5723166 Megabytes.
 <pre><code>
     % sudo lvm vgremove vg0
     Volume group "vg0" successfully removed
@@ -602,8 +604,6 @@
     Physical volume "/dev/rdk8" successfully created
     % sudo lvm pvcreate /dev/rdk9
     Physical volume "/dev/rdk9" successfully created
-    % sudo vgcreate vg0 /dev/rdk8 /dev/rdk9
-    sudo: vgcreate: command not found
     % sudo lvm vgcreate vg0 /dev/rdk8 /dev/rdk9
     Volume group "vg0" successfully created
     % sudo lvm pvs
@@ -626,10 +626,12 @@
     /dev/mapper/vg0-lvtest       470M       1.0K       447M   0% /mnt
 </code></pre>
 
-There is one issue with LVM on wedges. LVM scans disks for its label to coalesce them into
-volume groups and to find the logical volumes. You can restrict the search in the LVM
-configuration, but if you use wedges, you must scan all wedges as the name of the device may
-change. Also, the result of a scan is saved to optimize subsequent scans. If your disk
-configuration changes, you either need to remove the cached result or configure LVM to
-not save it with the write_cache_state option.
+There is one issue with LVM on wedges. LVM scans disks for its
+label to coalesce them into volume groups and to find the logical
+volumes. You can restrict the search in the LVM configuration, but
+if you use wedges, you must scan all wedges as the name of the
+device may change. Also, the result of a scan is saved to optimize
+subsequent scans. If your disk configuration changes, you either
+need to remove the cached result or configure LVM to not save it
+with the write_cache_state option.
 

use meta title for capitalization
Index: wikisrc/wiki/todo/make_toc_anchor_urls_permanent.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/wiki/todo/make_toc_anchor_urls_permanent.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/wiki/todo/make_toc_anchor_urls_permanent.mdwn	8 Dec 2014 12:40:32 -0000	1.1
+++ wikisrc/wiki/todo/make_toc_anchor_urls_permanent.mdwn	8 Dec 2014 14:04:42 -0000	1.2
@@ -1 +1,3 @@
+[[!meta title="make toc anchor URLs permanent"]]
+
 Currently anchors are named in section order, e.g. #index1h2. It would be nice if the anchor names were not volatile, so external links could reference a specific page section.

--- /dev/null	2014-12-08 14:20:00.000000000 +0000
+++ wikisrc/wiki/todo/make_toc_anchor_urls_permanent.mdwn	2014-12-08 14:26:43.000000000 +0000
@@ -0,0 +1 @@
+Currently anchors are named in section order, e.g. #index1h2. It would be nice if the anchor names were not volatile, so external links could reference a specific page section.

Update MAC address info.
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 20:13:34 -0000	1.41
+++ wikisrc/ports/evbarm/allwinner.mdwn	8 Dec 2014 11:57:38 -0000	1.42
@@ -148,13 +148,9 @@
 1: [*] audio1 @ awinhdmiaudio0: Allwinner HDMI 1.4, 2 playback channels
 """]]
 
-# Board specific notes
+# MAC address
 
-## Merrii Hummingbird A31
-
-There doesn't appear to be a meaningful way to generate a MAC address on these boards. U-Boot from the A31 SDK and from the u-boot-sunxi tree both lack GMAC support, and the Security ID registers (at 0x01c23800) appear to be empty.
-
-To overcome this, you can specify your own MAC address in *uEnv.txt*:
+On boards where the ethernet MAC address cannot be determmined, a random MAC address will be generated every boot. You can override this behaviour by specifying a MAC address in *uEnv.txt*:
 [[!template  id=programlisting text="""
 bootargs=root=ld0a awge0.mac-address=02:a0:3d:88:1a:1e
 """]]

eMMC works on A80 now
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 18:42:51 -0000	1.40
+++ wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 20:13:34 -0000	1.41
@@ -57,7 +57,6 @@
    - USB3 (OTG and XHCI)
    - IR transmitter
    - HDMI
-   - eMMC
    - Audio codec
  - All
    - USB device mode

Refresh TODO list
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 18:38:12 -0000	1.39
+++ wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 18:42:51 -0000	1.40
@@ -43,18 +43,27 @@
  - IR receiver (A20/A31/A80)
 
 # TODO
- - SoCs
-   - Cortex-A8: A10
-   - Cortex-A7/A15: A80 SMP
- - OTG (A31)
- - USB device mode
- - Bluetooth / WiFi (Cubietruck, Hummingbird A31)
- - 3G (Hummingbird A31)
- - SD/MMC UHS-I support (needs sdmmc(4) changes)
- - TV input (Hummingbird A31)
- - NAND
- - Fast Ethernet (EMAC)
- - IR transmitter (A20/A80)
+ - A10
+   - Interrupt controller
+   - EMAC
+ - A31
+   - OTG
+   - IR transmitter
+   - 3G module
+   - TV input
+ - A80
+   - MP
+   - big.LITTLE support
+   - USB3 (OTG and XHCI)
+   - IR transmitter
+   - HDMI
+   - eMMC
+   - Audio codec
+ - All
+   - USB device mode
+   - SD/MMC UHS-I support (needs sdmmc(4) changes)
+   - SDIO (Bluetooth / WiFi)
+   - NAND
 
 # Installation
 

IR receiver works on A80 now
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 14:32:02 -0000	1.38
+++ wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 18:38:12 -0000	1.39
@@ -40,7 +40,7 @@
    - DDC / EDID mode detection
    - Audio support
  - Framebuffer (A20/A31)
- - IR receiver (A20/A31)
+ - IR receiver (A20/A31/A80)
 
 # TODO
  - SoCs
@@ -54,7 +54,7 @@
  - TV input (Hummingbird A31)
  - NAND
  - Fast Ethernet (EMAC)
- - IR transmitter (A20)
+ - IR transmitter (A20/A80)
 
 # Installation
 

Link to Cubieboard 4 product page
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 14:28:37 -0000	1.37
+++ wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 14:32:02 -0000	1.38
@@ -5,7 +5,7 @@
 # Supported boards
  - [Banana Pi](http://www.bananapi.org/p/product.html) (BPI)
  - Cubieboard 2 (CUBIEBOARD)
- - Cubieboard 4 (ALLWINNER_A80) *NetBSD-current*
+ - [Cubieboard 4](http://cubieboard.org/model/cb4/) (ALLWINNER_A80) *NetBSD-current*
  - Cubietruck (CUBIETRUCK)
  - [Merrii Hummingbird A31](http://www.merrii.com/en/pla_d.asp?id=172) (HUMMINGBIRD_A31)
 

Note A80 RTC support, audio codec not supported on A80, OTG only on A20, framebuffer only for A20/A31
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 11:56:31 -0000	1.36
+++ wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 14:28:37 -0000	1.37
@@ -27,17 +27,19 @@
    - AXP809 (A80)
  - Watchdog timer
  - RTC
- - Audio codec
+   - A20/A31: integrated RTC, PCF8563
+   - A80: AC100
+ - Audio codec (A20/A31)
  - USB host
    - OHCI
    - EHCI
-   - OTG (not yet working on A31)
+   - OTG (A20)
  - SATA (A10/A20)
  - Gigabit Ethernet (GMAC)
  - HDMI (A20/A31)
    - DDC / EDID mode detection
    - Audio support
- - Framebuffer
+ - Framebuffer (A20/A31)
  - IR receiver (A20/A31)
 
 # TODO

Note A80 PMU support
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- wikisrc/ports/evbarm/allwinner.mdwn	5 Dec 2014 19:29:16 -0000	1.35
+++ wikisrc/ports/evbarm/allwinner.mdwn	7 Dec 2014 11:56:31 -0000	1.36
@@ -19,10 +19,12 @@
    - Configuration using FEX scripts is supported
  - UART
  - I2C
- - P2WI (A31)
+ - P2WI (A31) / RSB (A80)
  - PMU
-   - AXP209 (A20, A80)
+   - AXP209 (A20)
    - AXP221 (A31)
+   - AXP806 (A80)
+   - AXP809 (A80)
  - Watchdog timer
  - RTC
  - Audio codec

update ccd section
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- wikisrc/users/mlelstv/using-large-disks.mdwn	7 Dec 2014 09:21:27 -0000	1.23
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	7 Dec 2014 11:01:24 -0000	1.24
@@ -299,28 +299,13 @@
 type ccd to be used by the concatenating disk driver.
 
 ccd is a very old driver and has some deficiencies. For one, the ccdconfig
-tool doesn't understand wedge names.
+tool didn't understand wedge names until very recently.
 <pre><code>
    % sudo ccdconfig -c ccd0 16 none NAME=hugedisk1 NAME=hugedisk2
    ccdconfig: NAME=hugedisk1: No such file or directory
 </code></pre>
 
-This cannot easily be handled, because the NAME= syntax exists in userland.
-All tools that understand it, translate the wedge name into a device path.
-For ccd however, the component paths are passed to the kernel and are
-interpreted every time the ccd device is opened, but wedge paths (i.e.
-/dev/dkXX) become outdated easily. You can configure a ccd device, but
-when it is used, it might access the wrong disks.
-
-The cgd driver has a similar problem. A method to avoid this problem is
-to use devpubd to create and adjust symlinks for wedges.
-
-Despite the warning from ccdconfig, the device has been created and
-needs to be removed again. The warning comes from the attempt to read
-the disklabel from the first component.
-<pre><code>
-   % sudo ccdconfig -u ccd0
-</code></pre>
+The cgd driver has a similar problem.
 
 ## configuring
 For now we use the wedge device directly.

fix c&p error
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- wikisrc/users/mlelstv/using-large-disks.mdwn	6 Dec 2014 13:49:26 -0000	1.22
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	7 Dec 2014 09:21:27 -0000	1.23
@@ -225,9 +225,6 @@
     % sudo gpt show wd1
             start         size  index  contents
                 0  11721045168         
-    % sudo gpt show wd1
-            start         size  index  contents
-                0  11721045168         
     % sudo gpt create wd1
     % sudo gpt show wd1
             start         size  index  contents

mention makewedges
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- wikisrc/users/mlelstv/using-large-disks.mdwn	6 Dec 2014 13:39:02 -0000	1.21
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	6 Dec 2014 13:49:26 -0000	1.22
@@ -262,6 +262,16 @@
     % sudo drvctl -a ata_hl -r atabus4
 </code></pre>
 
+NetBSD-current as a of 20141104 can rescan a device for wedges instead.
+This will delete all unused wedges for a device and readd them according
+to the label.
+<pre><code>
+    % sudo dkctl wd1 makewedges
+    successfully scanned /dev/rwd1d.
+    % sudo dkctl wd2 makewedges
+    successfully scanned /dev/rwd2d.
+</code></pre>
+
 The console or dmesg will reveal that both disks have been reattached
 and wedges have been created:
 <pre><code>
@@ -403,7 +413,7 @@
   11721045167            1         Sec GPT header
 </code></pre>
 
-And the reattachment magic:
+And the reattachment magic (or remake the wedges on recent NetBSD):
 <pre><code>
     % sudo drvctl -d wd1
     % sudo drvctl -d wd2

more about LVM
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:26:59 -0000	1.20
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	6 Dec 2014 13:39:02 -0000	1.21
@@ -538,3 +538,106 @@
 available when booting and autoconfigures devices for all raidsets found that have the
 autoconfig flag set.
 
+# LVM
+
+Linux LVM is a different scheme to manage disk space, it uses its own label to group
+multiple disks together and to carve out blocks using the device mapper driver to
+form logical volumes.
+
+The device mapper provides logical block and character devices that route I/O to
+physical disks or some other logical devices. Such devices can be used for filesystems
+like a disk partition or wedge.
+
+LVM is mostly used on raw disks as there is rarely a necessity to partition a disk first.
+But it can also be used on disk partitions or wedges, this has advantages if the disks are used
+for booting or are moved between different systems or platforms.
+
+## LVM on raw disks
+
+LVM disks are labeled first with the pvcreate command and then coalesced into a volume group.
+<pre><code>
+    % sudo lvm pvcreate /dev/rwd1d
+    Physical volume "/dev/rwd1d" successfully created
+    % sudo lvm pvcreate /dev/rwd2d
+    Physical volume "/dev/rwd2d" successfully created
+    % sudo lvm vgcreate vg0 /dev/rwd1d /dev/rwd2d
+    Volume group "vg0" successfully created
+    % sudo lvm pvs
+    PV         VG   Fmt  Attr PSize PFree
+    /dev/rwd1d vg0  lvm2 a-   2.00t 2.00t
+    /dev/rwd2d vg0  lvm2 a-   2.00t 2.00t
+</code></pre>
+
+This shows a problem with large disks, the LVM tools only understand conventional disk partitions
+that are limited to 2TB each. However, neither LVM, the device mapper driver or the disk drivers
+when using the raw partition are bound to the disklabel information. But you need to tell LVM
+the real size to override the synthesized disklabel. The real size is 11721045168 sectors
+by 512 bytes giving 5723166 Megabytes.
+<pre><code>
+    % sudo lvm vgremove vg0
+    Volume group "vg0" successfully removed
+    % sudo lvm pvcreate --setphysicalvolumesize=5723166 /dev/rwd1d
+    WARNING: /dev/rwd1d: Overriding real size. You could lose data.
+    Physical volume "/dev/rwd1d" successfully created
+    % sudo lvm pvcreate --setphysicalvolumesize=5723166 /dev/rwd2d
+    WARNING: /dev/rwd2d: Overriding real size. You could lose data.
+    Physical volume "/dev/rwd2d" successfully created
+    % sudo lvm vgcreate vg0 /dev/rwd1d /dev/rwd2d
+    Volume group "vg0" successfully created
+    % sudo lvm pvs
+    PV         VG   Fmt  Attr PSize PFree
+    /dev/rwd1d vg0  lvm2 a-   5.46t 5.46t
+    /dev/rwd2d vg0  lvm2 a-   5.46t 5.46t
+</code></pre>
+
+## LVM on wedges
+
+Here are again the two disks with a large wedge each. The wedge type is unknown
+because the GPT lists the partition as type linux-lvm which has no well-known
+wedge type.
+<pre><code>
+    % sudo dkctl wd1 listwedges
+    /dev/rwd1d: 1 wedge:
+    dk8: hugedisk1, 11721045100 blocks at 34, type: 
+    % sudo dkctl wd2 listwedges
+    /dev/rwd2d: 1 wedge:
+    dk9: hugedisk2, 11721045100 blocks at 34, type: 
+</code></pre>
+
+Now label the disks, form a volume group, create a logical partition and a filesystem:
+<pre><code>
+    % sudo lvm pvcreate /dev/rdk8
+    Physical volume "/dev/rdk8" successfully created
+    % sudo lvm pvcreate /dev/rdk9
+    Physical volume "/dev/rdk9" successfully created
+    % sudo vgcreate vg0 /dev/rdk8 /dev/rdk9
+    sudo: vgcreate: command not found
+    % sudo lvm vgcreate vg0 /dev/rdk8 /dev/rdk9
+    Volume group "vg0" successfully created
+    % sudo lvm pvs
+    PV         VG   Fmt  Attr PSize PFree
+    /dev/rdk8  vg0  lvm2 a-   5.46t 5.46t
+    /dev/rdk9  vg0  lvm2 a-   5.46t 5.46t
+    % sudo lvm lvcreate -L 500m -n lvtest vg0
+    Logical volume "lvtest" created
+    % sudo newfs -O2 /dev/vg0/lvtest
+    /dev/mapper/rvg0-lvtest: 500.0MB (1024000 sectors) block size 8192, fragment size 1024
+    using 11 cylinder groups of 45.46MB, 5819 blks, 10976 inodes.
+    super-block backups (for fsck_ffs -b #) at:
+    144, 93248, 186352, 279456, 372560, 465664, 558768, 651872, 744976, 838080,
+    ...............................................................................
+    % sudo mount /dev/vg0/lvtest /mnt
+    mount_ffs: "/dev/vg0/lvtest" is a non-resolved or relative path.
+    mount_ffs: using "/dev/mapper/vg0-lvtest" instead.
+    % df -h /mnt
+    Filesystem                   Size       Used      Avail %Cap Mounted on
+    /dev/mapper/vg0-lvtest       470M       1.0K       447M   0% /mnt
+</code></pre>
+
+There is one issue with LVM on wedges. LVM scans disks for its label to coalesce them into
+volume groups and to find the logical volumes. You can restrict the search in the LVM
+configuration, but if you use wedges, you must scan all wedges as the name of the device may
+change. Also, the result of a scan is saved to optimize subsequent scans. If your disk
+configuration changes, you either need to remove the cached result or configure LVM to
+not save it with the write_cache_state option.
+

Added a comment: Some progress made...
--- /dev/null	2014-12-08 14:20:00.000000000 +0000
+++ wikisrc/projects/project/compressed-cache/comment_2_88539113a221d856341eff93fedde6ed._comment	2014-12-08 14:26:43.000000000 +0000
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl75SoWPmoCcnFFpxrvaFCEkBWjgvVYViQ"
+ nickname="Vinaykumar"
+ subject="Some progress made..."
+ date="2014-12-05T22:27:23Z"
+ content="""
+.. the git repo can be found here - https://github.com/vnaybhat/ccache
+"""]]

Add some A80 notes
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- wikisrc/ports/evbarm/allwinner.mdwn	22 Nov 2014 13:41:58 -0000	1.34
+++ wikisrc/ports/evbarm/allwinner.mdwn	5 Dec 2014 19:29:16 -0000	1.35
@@ -5,12 +5,14 @@
 # Supported boards
  - [Banana Pi](http://www.bananapi.org/p/product.html) (BPI)
  - Cubieboard 2 (CUBIEBOARD)
+ - Cubieboard 4 (ALLWINNER_A80) *NetBSD-current*
  - Cubietruck (CUBIETRUCK)
  - [Merrii Hummingbird A31](http://www.merrii.com/en/pla_d.asp?id=172) (HUMMINGBIRD_A31)
 
 # Supported hardware
  - SoCs
-   - Cortex-A7: A20 (2-core), A31 (4-core)
+   - Cortex-A7: A20 (2-core), A31 (4-core), A80
+   - Cortex-A7/A15: A80 (4-core A7 + 4-core A15)
  - SD/MMC controller (DMA)
  - DMA controller
  - GPIO
@@ -19,7 +21,7 @@
  - I2C
  - P2WI (A31)
  - PMU
-   - AXP209 (A20)
+   - AXP209 (A20, A80)
    - AXP221 (A31)
  - Watchdog timer
  - RTC
@@ -39,7 +41,7 @@
 # TODO
  - SoCs
    - Cortex-A8: A10
-   - Cortex-A7/A15: A80
+   - Cortex-A7/A15: A80 SMP
  - OTG (A31)
  - USB device mode
  - Bluetooth / WiFi (Cubietruck, Hummingbird A31)
@@ -70,6 +72,25 @@
 uenvcmd=mmc dev 0; mmc rescan; fatload mmc 0:1 82000000 netbsd.ub; bootm 82000000
 """]]
 
+## A80 based boards
+
+* Cubieboard 4 SDK (lubuntu) U-Boot env:
+[[!template  id=programlisting text="""
+baudrate=115200
+boot_normal=fatload mmc 0:1 20007800 uimage;bootm 20007800
+bootcmd=run setargs_cubie boot_normal
+bootdelay=3
+console=ttyS0,115200
+console1=tty1
+init=/init
+loglevel=8
+mmc_root=/dev/mmcblk0p2
+setargs_cubie=setenv bootargs console=${console1} console=${console} root=${mmc_root} loglevel=${loglevel}
+stderr=serial
+stdin=serial
+stdout=serial
+"""]]
+
 # Big (endian) fun
 
 You can run this boards with a little endian (this is the default and implied by above install instructions)

Time has passed. textproc/po4a has been updated.
Index: wikisrc/wiki/todo/be_multilingual.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/wiki/todo/be_multilingual.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/wiki/todo/be_multilingual.mdwn	26 Nov 2009 01:37:12 -0000	1.2
+++ wikisrc/wiki/todo/be_multilingual.mdwn	3 Dec 2014 20:16:22 -0000	1.3
@@ -1,19 +1,3 @@
 ikiwiki is translatable with [[!iki plugins/po]] (see it in action
-at [l10n.ikiwiki.info](http://l10n.ikiwiki.info/)).
-
-`textproc/po4a` needs to be updated for this feature to work, which
-in turn needs an updated `devel/gettext` (for a particular `msgmerge`
-parameter). Updating `gettext` has the following fallout for netbsd-4,
-as explained by [[joerg]]:
-
-7. netbsd-4 doesn't support positional arguments for `printf`
-7. gettext will force macros for `*printf` and all programs including
-`libintl.h` also have to link against `-lintl` if they use `printf`
-7. forcefully adding libintl is not exactly my idea of a correct
-solution
-7. and the problem of `/usr/lib/libintl.so` vs
-`/usr/pkg/lib/libintl.so` still remains
-
-We can update `devel/gettext` if we fix the netbsd-4 fallout. Then
-updating `textproc/po4a` should be easy. Then we can experiment
-with translating this wiki.
+at [l10n.ikiwiki.info](http://l10n.ikiwiki.info/)). If we can enable
+the plugin, we can experiment with translating this wiki.

Added a comment: details for iMac G4
--- /dev/null	2014-12-08 14:20:00.000000000 +0000
+++ wikisrc/tutorials/how_to_install_netbsd_on_a_power_macintosh_g4___40__grey__41__/comment_1_ce6b3a02d35a0f3b9039c7666e14712a._comment	2014-12-08 14:26:43.000000000 +0000
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnFSoiuvQI4SDhKnmmgzvjLQNZtibINcZw"
+ nickname="Timothy"
+ subject="details for iMac G4"
+ date="2014-11-25T04:39:34Z"
+ content="""
+This is a really nice page, thank you. I just installed NetBSD 6.1.5 onto the notoriously quirky iMac G4 (take a look at some of the Debian/MintPPC/Ubuntu posts to see how nicely it plays with the nouveau driver) and I needed some workarounds, but otherwise these instructions worked well. I wanted to add this comment for people with that system, since it doesn't play nice.
+
+follow these instructions closely, except alter the following:
+
+don't bother trying to set up networking with sysinst- it doesn't do dhcp on this computer
+
+pdisk is included on the 6.1.5 cd, so it doesn't need downloaded
+
+newfs won't work on this setup with the command listed above, use #newfs /dev/rwd0c
+
+(r for raw)
+
+after installing the sets quit sysinst and chroot into the new installation
+
+# mount /dev/wd0a /mnt2
+#chroot /mnt2
+edit the rc.conf
+#vi rc.conf
+change configured to YES, 
+dhclient=yes 
+hostname=yourhost 
+wscons=yes
+sshd= yes
+
+add a root password
+#passwd
+
+add a user and put her in group wheel
+# useradd -m -G wheel joe
+
+give them a password too.
+
+start sshd
+# /etc/rc.d/sshd start
+edit fstab one more time to enable pty (needed to ssh in, at least on my computer)
+
+#vi /etc/fstab
+
+add the line
+
+ptyfs /dev/pts ptyfs rw 0 0
+
+save, exit, reboot, boot cd:,ofwboot.xcf hd:3,/netbsd
+
+
+and when the computer comes back up, it will show the kernel messages and then nothing. the messages will then scroll off the screen and there'll be an invisible console present. hence the need for ssh 
+ssh in from another computer, and do whatever configuration you want from that console
+or, hit enter a few times to specify terminal type, etc, type your name, hit enter, password, hit enter, and then startx. x will load with twm as the window manager. 
+
+I can't get hformat to work with this version or this computer. It compiled correctly, but it will not format my boot partition. So I just use the cd to boot.
+
+Thanks for your work putting this together! NetBSD was my savior when the Debian family switched from nv to nouveau. the iMac G4 needs nv.
+
+
+"""]]

Use onestart, not start, if the daemon is not yet enabled in rc.conf.
Index: wikisrc/tutorials/how_to_set_up_nfs_and_nis.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_set_up_nfs_and_nis.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/tutorials/how_to_set_up_nfs_and_nis.mdwn	5 Feb 2012 07:14:36 -0000	1.2
+++ wikisrc/tutorials/how_to_set_up_nfs_and_nis.mdwn	24 Nov 2014 02:18:26 -0000	1.3
@@ -116,10 +116,10 @@
 
 This exports /home only on the LAN 192.168.x.x. The maproot line is needed, because otherwise the client's root will not have superuser access. Now, start the mount daemon and the NFS deamons (mountd and nfsd) as root on your server, in that order. For that type: 
     
-     root@mars# /etc/rc.d/rpcbind start
-     root@mars# /etc/rc.d/mountd start
-     root@mars# /etc/rc.d/nfsd start
-     root@mars# /etc/rc.d/nfslocking start
+     root@mars# /etc/rc.d/rpcbind onestart
+     root@mars# /etc/rc.d/mountd onestart
+     root@mars# /etc/rc.d/nfsd onestart
+     root@mars# /etc/rc.d/nfslocking onestart
     
 
 If you wish to start the NFS server on boot, add following lines to your /etc/rc.conf 

A31 installation instructions
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- wikisrc/ports/evbarm/allwinner.mdwn	18 Nov 2014 08:17:22 -0000	1.33
+++ wikisrc/ports/evbarm/allwinner.mdwn	22 Nov 2014 13:41:58 -0000	1.34
@@ -52,10 +52,12 @@
 
 # Installation
 
-## A10 / A20 based boards
+## A10 / A20 / A31 based boards
 
 * Start with an ARMv7 image from *evbarm-earmv7hf/binary/gzimg/* such as *beagleboard.img*
-* Download a U-Boot build for your board from the linux-sunxi web site <http://dl.linux-sunxi.org/nightly/u-boot-sunxi/u-boot-sunxi/u-boot-sunxi-latest/>
+* Download a U-Boot build for your board
+  * A10/A20: Download from the linux-sunxi web site <http://dl.linux-sunxi.org/nightly/u-boot-sunxi/u-boot-sunxi/u-boot-sunxi-latest/>
+  * A31: The standard u-boot-sunxi tree doesn't support A31 yet. Until sun6i support is merged, a build is available at <http://dis.invisible.ca/allwinner/a31/> 
 * Write the *u-boot-sunxi-with-spl.bin* loader to the base image:
 [[!template  id=programlisting text="""
 # dd if=u-boot-sunxi-with-spl.bin of=beagleboard.img bs=1k seek=8 conv=notrunc
@@ -68,10 +70,6 @@
 uenvcmd=mmc dev 0; mmc rescan; fatload mmc 0:1 82000000 netbsd.ub; bootm 82000000
 """]]
 
-## A31 based boards
-
-TBD.
-
 # Big (endian) fun
 
 You can run this boards with a little endian (this is the default and implied by above install instructions)

add 5.1.5 and 5.2.3. grrrrr.
Index: wikisrc/releng.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/releng.mdwn	4 Nov 2014 05:59:20 -0000	1.12
+++ wikisrc/releng.mdwn	19 Nov 2014 07:56:38 -0000	1.13
@@ -32,9 +32,9 @@
 * Next Minor release: NetBSD 5.3 (No release date proposed)
   + CVS branch tag: <code>netbsd-5</code>
 * Actively supported teeny releases:
-  + [NetBSD 5.2.2](http://www.netbsd.org/releases/formal-5/NetBSD-5.2.2.html)
+  + [NetBSD 5.2.3](http://www.netbsd.org/releases/formal-5/NetBSD-5.2.3.html)
     - CVS branch tag: <code>netbsd-5-2</code>
-  + [NetBSD 5.1.4](http://www.netbsd.org/releases/formal-5/NetBSD-5.1.4.html)
+  + [NetBSD 5.1.5](http://www.netbsd.org/releases/formal-5/NetBSD-5.1.5.html)
     - CVS branch tag: <code>netbsd-5-1</code>
 * [Current pull-up queue for the netbsd-5 branch](http://releng.netbsd.org/cgi-bin/req-5.cgi)
 

there is no beaglebone.img. use beagleboard.img.
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- wikisrc/ports/evbarm/allwinner.mdwn	17 Nov 2014 18:52:42 -0000	1.32
+++ wikisrc/ports/evbarm/allwinner.mdwn	18 Nov 2014 08:17:22 -0000	1.33
@@ -54,11 +54,11 @@
 
 ## A10 / A20 based boards
 
-* Start with an ARMv7 image from *evbarm-earmv7hf/binary/gzimg/* such as *beaglebone.img*
+* Start with an ARMv7 image from *evbarm-earmv7hf/binary/gzimg/* such as *beagleboard.img*
 * Download a U-Boot build for your board from the linux-sunxi web site <http://dl.linux-sunxi.org/nightly/u-boot-sunxi/u-boot-sunxi/u-boot-sunxi-latest/>
 * Write the *u-boot-sunxi-with-spl.bin* loader to the base image:
 [[!template  id=programlisting text="""
-# dd if=u-boot-sunxi-with-spl.bin of=beaglebone.img bs=1k seek=8 conv=notrunc
+# dd if=u-boot-sunxi-with-spl.bin of=beagleboard.img bs=1k seek=8 conv=notrunc
 """]]
 * Write the image to an SD card.
 * Copy the kernel (netbsd.ub) for your board to the root of the MS-DOS partition.

IR receiver works on A20 and A31. IR transmitter on A20 is not supported.
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- wikisrc/ports/evbarm/allwinner.mdwn	15 Nov 2014 16:14:47 -0000	1.31
+++ wikisrc/ports/evbarm/allwinner.mdwn	17 Nov 2014 18:52:42 -0000	1.32
@@ -34,7 +34,7 @@
    - DDC / EDID mode detection
    - Audio support
  - Framebuffer
- - IR (A31)
+ - IR receiver (A20/A31)
 
 # TODO
  - SoCs
@@ -48,7 +48,7 @@
  - TV input (Hummingbird A31)
  - NAND
  - Fast Ethernet (EMAC)
- - IR (A20)
+ - IR transmitter (A20)
 
 # Installation
 

Added a comment: Using NetBSD based sockets, implement a TCP client and TCP Server to demonstrate trivially secure file download from server.
--- /dev/null	2014-12-08 14:20:00.000000000 +0000
+++ wikisrc/examples/socket_programming/comment_3_26d8d43c8a023ee0832a8dda5c1d6eb8._comment	2014-12-08 14:26:44.000000000 +0000
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnuJe4W1NBJVj6pfcQVO7Ebicw3Yzpq6mE"
+ nickname="Niranjan"
+ subject="Using NetBSD based sockets, implement a TCP client and TCP Server to demonstrate trivially secure file download from server."
+ date="2014-11-17T08:26:08Z"
+ content="""
+Using NetBSD based sockets, implement a TCP client and TCP Server to demonstrate trivially secure file download from server.
+
+Environment/Tools required: Linux RHEL4/5/6 and gcc/g++ compiler and vi editor (recommended) OR Windows XP/Vista/7/8 with Visual studio.
+
+Learning Objective for student:
+
+Understand Protocol messaging and parsing.
+Manage multiple connections at a server side
+Manage the state of a connection at both client and server side.
+Ability to use NetBSD Sockets via C API.
+Binary vs Text and practical issues with Endianness !
+Ability to effectively use fread, fwrite APIs for file management
+can also use read/write system calls.
+Understanding Standards and compatibility (and the inherent difficulty!) between different (not differing!) implementations. Note: This is a group assignment. Each group can have maximum of 10 students.
+If group of 10 students is opted, 5 students may contribute to the client and another 5 students may contribute to the server. but put together at a minimum, the expected result is a group's server should work with its own client.
+If a group's server/client are compatible with other group's client/servers, it will receive more credit. ** Each group is expected to write both the client and a server.\" -1- Details:
+The messaging mechanism is based on Type-Length-Value (TLV) The Message Format is TYPE Field ---- Length Field --- Value field --------------- ---- 8 bytes --- 4 Bytes int ---- buffer of length bytes ---- Note: If Length Field is ZERO, then the Value field is empty which is still a perfectly valid message.
+eg. LOGINOK message - See details below.
+All types are of size 8 chars and always uppercase. Valid Types for Client messages are: LOGIN, AUTH, GETFILE Valid Types for Server messages are: NEEDAUTH, LOGINOK, DATA, ERROR As Type field is 8 bytes, it will employ 'SPACE' as padding. i.e. LOGIN will be sent as \"LOGIN \"
+The message exchange details are as below: Client connects to the server. LOGIN is the first message sent by the client. If server requires authentication, it replies with NEEDAUTH message. If server does not require authentication, it replies with LOGINOK message. Client sends back AUTH message as a reply to NEEDAUTH message Server replies with LOGINOK if authentication successful, else replies will reply with ERROR and close the connection. Client if login was ok, i.e. received LOGINOK message, can send at any time, a file download request by sending the message GETFILE. Note: Only outgoing request must be in the network pipe. Upon receiving a GETFILE message, if server finds a matching file it can send the file contents back in the DATA message. If no matching file, it may send back an ERROR message.
+Note, any time the client can close the connection and go away,
+server needs to detect this and close the connection on its side as well. eg. if while server is sending a file, the client goes away, server needs to stop then and there. -2-
+The Client upon receiving the DATA message should store the contents appropriately into a file for later viewing.
+Server never advertises the file list on the server (unlike SCP/SFTP/FTP !)
+so clients need to know the file names
+a simple way is to query the user Note: A fancy UI is not required, rather a basic working UI with scanf() or fgets() should suffice. Note about GETFILE: The GETFILE message can send as value a full path name (absolute) or a relative path name. with \"/\" as directory separator. eg. If \"hello/details.txt\" is sent, server is supposed to look in its working directory the given path of the file. So in this case \"hello/details.txt\" and \"details.txt\" may refer to completely different files. Command Line arguments:
+./TSServer ./TSClient Note about Auth Mechanism: Any 2-way auth mechanism can be employed, trivially a Salted Password hash based mechanism can be employed. This avoids replay attacks! NOTE: * If the environment chosen is Linux, it comes with a tool called 'md5sum' which can be used to generate the Hashes on both client side and server side. * The server can store the list of passwords in some file. (Bad! Not secure, but ok for this barebones version) * Both the server and client programs may run in the same machine during development, but for testing it would be ideal to run them in different machines, to see how a client/server reacts when network goes away. ( Intentionally pull out the ethernet cable when the client is downloading a big file!) -3-
+
+Message Details
+
+There are totally 7 messages - Syntax/Structure is as below. 1. LOGIN 2. NEEDAUTH - randomly generated 3. AUTH 4. LOGINOK - no value sent. O byte length 5. ERROR - can be 0 byte length or contain an error string 6. GETFILE 7. DATA - x bytes indicating size + x bytes of data Note: x can be 0. which means empty file! A Sample Messaging
+
+C - Client; S - Server
+
+C: LOGIN rajesh S: NEEDAUTH aa1123 C: AUTH <Hash(Password + aa1123)> S: LOGINOK C: GETFILE detail.txt S: ERROR \"No Such file\" C: GETFILE details.txt S: DATA 100 \"some data ... of 100 bytes\" Client closes the connection after receiving the DATA and stores the data received into a file.
+
+Extras/Optional: (Attempting will lead to Extra credit)
+
+Server side : 1. Server can timeout an idle connection, where the idle timeout can be set as a command line argument. 2. Server can close the connection if client sends 'x' number of bad GETFILE messages. 'x' can be made configurable. 3. Server side handling of BAD Clients sending BAD/Invalid Messages/Out-of-Sequence Messages eg. A Client connecting and trying to send GETFILE Message without sending LOGIN 4. Implementing a simple Server side log with timestamp. 5. Server support for parallel multiple client connections with select() and FDSET mechanism of checking socket data availability or truly parallel threaded server! -4- Client side: 1. Supporting Parallel Connections to download multiple files from the server at a same time. eg. Via the UI can get the list of files as input from the user and open multiple parallel connections to the server send it to the server and start downloading the files at the same time. - Will need to reuse the connections as well. 2. Implementing a simple Client side download log with timestamp. 3. Take a download folder as a command line argument and all downloaded files with unique names to be stored in this folder. eg. if same file is downloaded twice, each filename will be unique by suffixing it with a timestamp. Note: As can be seen, the filesize in this barebones mechanism is restricted to 232 bytes - 4GB as the length field is only 4 Bytes. Extras (needs both server and client side co-operative changes) - Ability to support better Authentication schemes. - Ability to support big files on server side and client side - Ability to support RANGE where the server can send a portion of the file.
+
+RANGE message syntax:
+
+RANGE start end --- Value field has delimiter as CRLF \"\r\n\" eg. RANGE details.txt 20 300 When server receives a RANGE message it reads the file only the range requested i.e. 20 to 300 bytes (both inclusive) and returns that data. so data size will be typically end-start+1 bytes in this case 300-20+1 = 281 bytes Of course, if the file is much smaller than 300 bytes, server can only send the available bytes. Server should not choke on invalid RANGE values sent by a client, if 'start' is greater than 'end', etc.
+"""]]

Remove Cubieboard from supported list. Create a new "SoCs" section in TODO list, mention A10 and A80 here.
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- wikisrc/ports/evbarm/allwinner.mdwn	15 Nov 2014 13:44:42 -0000	1.30
+++ wikisrc/ports/evbarm/allwinner.mdwn	15 Nov 2014 16:14:47 -0000	1.31
@@ -4,13 +4,12 @@
 
 # Supported boards
  - [Banana Pi](http://www.bananapi.org/p/product.html) (BPI)
- - Cubieboard, Cubieboard 2 (CUBIEBOARD)
+ - Cubieboard 2 (CUBIEBOARD)
  - Cubietruck (CUBIETRUCK)
  - [Merrii Hummingbird A31](http://www.merrii.com/en/pla_d.asp?id=172) (HUMMINGBIRD_A31)
 
 # Supported hardware
  - SoCs
-   - Cortex-A8: A10
    - Cortex-A7: A20 (2-core), A31 (4-core)
  - SD/MMC controller (DMA)
  - DMA controller
@@ -38,6 +37,9 @@
  - IR (A31)
 
 # TODO
+ - SoCs
+   - Cortex-A8: A10
+   - Cortex-A7/A15: A80
  - OTG (A31)
  - USB device mode
  - Bluetooth / WiFi (Cubietruck, Hummingbird A31)

IR works on A31 now
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- wikisrc/ports/evbarm/allwinner.mdwn	15 Nov 2014 00:26:59 -0000	1.29
+++ wikisrc/ports/evbarm/allwinner.mdwn	15 Nov 2014 13:44:42 -0000	1.30
@@ -35,6 +35,7 @@
    - DDC / EDID mode detection
    - Audio support
  - Framebuffer
+ - IR (A31)
 
 # TODO
  - OTG (A31)
@@ -45,7 +46,7 @@
  - TV input (Hummingbird A31)
  - NAND
  - Fast Ethernet (EMAC)
- - IR
+ - IR (A20)
 
 # Installation
 

Mention options for dealing with overscan.
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- wikisrc/ports/evbarm/allwinner.mdwn	12 Nov 2014 10:41:57 -0000	1.28
+++ wikisrc/ports/evbarm/allwinner.mdwn	15 Nov 2014 00:26:59 -0000	1.29
@@ -97,6 +97,8 @@
 
 To use HDMI for the console device, add *console=fb* to bootargs in uEnv.txt.
 
+If the connected display does not let you disable overscan, you can add a margin to the framebuffer by with the *fb.margin* bootargs option. For example, to set a 25-pixel margin around the screen, add *fb.margin=25* to uEnv.txt
+
 # HDMI audio
 
 The default audio device is the analog audio codec. To change the default device, use the *audiocfg* command:

TODO: IR
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- wikisrc/ports/evbarm/allwinner.mdwn	12 Nov 2014 00:47:19 -0000	1.27
+++ wikisrc/ports/evbarm/allwinner.mdwn	12 Nov 2014 10:41:57 -0000	1.28
@@ -45,6 +45,7 @@
  - TV input (Hummingbird A31)
  - NAND
  - Fast Ethernet (EMAC)
+ - IR
 
 # Installation
 

How to change the default audio device
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- wikisrc/ports/evbarm/allwinner.mdwn	11 Nov 2014 17:25:47 -0000	1.26
+++ wikisrc/ports/evbarm/allwinner.mdwn	12 Nov 2014 00:47:19 -0000	1.27
@@ -96,6 +96,21 @@
 
 To use HDMI for the console device, add *console=fb* to bootargs in uEnv.txt.
 
+# HDMI audio
+
+The default audio device is the analog audio codec. To change the default device, use the *audiocfg* command:
+
+[[!template  id=programlisting text="""
+a31# audiocfg list
+0: [*] audio0 @ awinac0: Allwinner CODEC A31, 2 playback channels
+1: [ ] audio1 @ awinhdmiaudio0: Allwinner HDMI 1.4, 2 playback channels
+a31# audiocfg default 1
+setting default audio device to audio1
+a31# audiocfg list
+0: [ ] audio0 @ awinac0: Allwinner CODEC A31, 2 playback channels
+1: [*] audio1 @ awinhdmiaudio0: Allwinner HDMI 1.4, 2 playback channels
+"""]]
+
 # Board specific notes
 
 ## Merrii Hummingbird A31

Note DDC, EDID, and HDMI audio support
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- wikisrc/ports/evbarm/allwinner.mdwn	10 Nov 2014 18:32:49 -0000	1.25
+++ wikisrc/ports/evbarm/allwinner.mdwn	11 Nov 2014 17:25:47 -0000	1.26
@@ -32,6 +32,8 @@
  - SATA (A10/A20)
  - Gigabit Ethernet (GMAC)
  - HDMI (A20/A31)
+   - DDC / EDID mode detection
+   - Audio support
  - Framebuffer
 
 # TODO

Document "console=fb" boot option
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- wikisrc/ports/evbarm/allwinner.mdwn	10 Nov 2014 18:29:01 -0000	1.24
+++ wikisrc/ports/evbarm/allwinner.mdwn	10 Nov 2014 18:32:49 -0000	1.25
@@ -90,6 +90,10 @@
 
 Some pre-compiled .bin files can be found here: <http://ftp.netbsd.org/pub/NetBSD/misc/jmcneill/allwinner/fex/>
 
+# Framebuffer console
+
+To use HDMI for the console device, add *console=fb* to bootargs in uEnv.txt.
+
 # Board specific notes
 
 ## Merrii Hummingbird A31

HDMI and frame buffer is supported now
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- wikisrc/ports/evbarm/allwinner.mdwn	5 Nov 2014 01:22:36 -0000	1.23
+++ wikisrc/ports/evbarm/allwinner.mdwn	10 Nov 2014 18:29:01 -0000	1.24
@@ -31,10 +31,10 @@
    - OTG (not yet working on A31)
  - SATA (A10/A20)
  - Gigabit Ethernet (GMAC)
+ - HDMI (A20/A31)
+ - Framebuffer
 
 # TODO
- - HDMI (some work completed here for A20)
- - Framebuffer
  - OTG (A31)
  - USB device mode
  - Bluetooth / WiFi (Cubietruck, Hummingbird A31)

Added a comment: Various Tuning Performance stuff
--- /dev/null	2014-12-08 14:20:00.000000000 +0000
+++ wikisrc/How_to_increase_ulimit_with_rc.conf/comment_1_5410f793fe33e9076e47b299e9ffe84f._comment	2014-12-08 14:26:45.000000000 +0000
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~emmanuel-kasper"
+ nickname="emmanuel-kasper"
+ subject="Various Tuning Performance stuff"
+ date="2014-11-07T18:39:41Z"
+ content="""
+is although here:http://wiki.netbsd.org/tutorials/tuning_netbsd_for_performance/
+"""]]

no need to rename ISOs anymore
Index: wikisrc/releng/release-prep.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng/release-prep.mdwn,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- wikisrc/releng/release-prep.mdwn	5 Nov 2014 21:02:55 -0000	1.16
+++ wikisrc/releng/release-prep.mdwn	7 Nov 2014 04:32:36 -0000	1.17
@@ -99,7 +99,6 @@
    and proceed.
 
 8. Create ISOs (macppc, mac68k, source).  See below for instructions.
-   Rename ISOs to blahcd-&lt;release&gt;.iso (for 6.0 and beyond, NetBSD-&lt;version&gt;-&lt;port&gt;.iso)
    Create hashes for ISOs (<code>cksum -a sha512 NetBSD* > SHA512</code>)
 
 9. rsync to nbftp.  It goes to a staging dir in /pub/NetBSD/misc/releng first.

Fix typo "aditional" -> "additional"
Index: wikisrc/ports/evbarm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/ports/evbarm.mdwn	6 Nov 2014 16:44:21 -0000	1.12
+++ wikisrc/ports/evbarm.mdwn	6 Nov 2014 16:46:23 -0000	1.13
@@ -281,7 +281,7 @@
 * Other devices inserted into the PC/104 (_isa_) expansion slot
 
 """
-aditional="""
+additional="""
   * The [NetBSD Diskless HOWTO](/docs/network/netboot/)
   * [ Porting NetBSD/evbarm to the Arcom Viper](http://www.cs.hut.fi/~pooka/pubs/EuroBSDCon2005/viper.pdf), presented at EuroBSDCon 2005. 
 """

Sort the supported hardware list.
Index: wikisrc/ports/evbarm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/ports/evbarm.mdwn	6 Nov 2014 16:40:19 -0000	1.11
+++ wikisrc/ports/evbarm.mdwn	6 Nov 2014 16:44:21 -0000	1.12
@@ -18,40 +18,41 @@
 
 [[!toc startlevel=3]]
 
-### Raspberry Pi Foundation **Raspberry Pi**
-The [[Raspberry Pi]] is a low-cost credit-card-sized computer from the Raspberry Pi Foundation.
+### ADI Engineering **BRH** ("Big Red Head") 
 
-### BeagleBoard.org **BeagleBone**
-The [[BeagleBone]] is a low-cost credit-card-sized computer from BeagleBoard.
+The BRH is an evaluation and development platform for the Intel **i80200**
+XScale processor. The BRH is based on ADI's **BECC** ("Big Endian Companion
+Chip"). The BRH is capable of both big- and little-endian operation, although
+NetBSD currently only supports little-endian operation. More information about
+the BRH can be found on [ADI Engineering's web
+page](http://www.adiengineering.com/productsBRH.html).
+
+Support for the BRH was written by Jason Thorpe, and contributed by Wasabi
+Systems, Inc.
+
+ * On-board NS16550-compatible serial ports (_com_)
+ * On-board Intel i82559 Ethernet on the PCI bus (_fxp_)
+ * On-chip timer on the BECC (used as system clock)
+ * Other devices inserted into the PCI slot
+
+The BRH comes with 128M of SDRAM. Systems with BECC revision 7 or less are
+limited to 64M due to the layout of the PCI DMA windows. Users of these
+systems should obtain an FPGA upgrade from ADI to revision 8 or later of the
+BECC.
 
 ### Allwinner Technology A10/A20/A31
 Various boards based on [[Allwinner]] SoCs are supported, including the BananaPi, Cubieboard, Cubieboard 2, Cubietruck, and Merrii Hummingbird A31.
 
-### Technologic Systems **TS-7200**
+### Arcom **Viper**
 
-The TS-7200 is a low-cost mass-produced PC/104 embedded single board computer
-intended as a general purpose core for real embedded applications. The TS-7200
-uses the Cirrus Logic EP9302 ARM9 system-on-chip and comes with a PC/104 (isa)
-bus and can either boot to CompactFlash or onboard flash. The board also has
-general purpose digital IO and optional multichannel analog-to-digital
-converters. More information on the TS-7200 can be found at [Technologic
-Systems](http://www.embeddedarm.com/epc/ts7200-spec-h.html).
+The Arcom Viper is a single board computer based on the PXA255 XScale
+processor.
 
-Support for the TS-7200 was written by Jesse Off
+Support for the Arcom Viper was written by Antti Kantee.
 
-* On-CPU RS232 UARTs (2) (_epcom_)
-* On-CPU 10/100 Ethernet MAC (_epe_)
-* CompactFlash socket (_wdc_)
-* USB 1.1 ports (2) (_ohci_)
-* Watchdog timer on CPLD (_tspld_)
-* TMP124 high precision temperature sensor via sysctl
-* 64Hz system clock from on-CPU timers (_epclk_)
-* HD44780 2x24 text mode LCD (_tslcd_)
-* 4x4 16 button matrix keypad (_wskbd_)
-* TS-5620 battery backed RTC daughter-card (_tsrtc_)
-* 1,2,4 port serial TS-SER daughter cards (_com_)
-* Up to 4 10Mb TS-ETH10 daughter cards (_tscs_)
-* Other devices inserted into the PC/104 (_isa_) expansion slot
+ * On-chip timers (_saost_ used as system clock)
+ * On-chip serial ports (_com_)
+ * On-board SMC91C111 ethernet (_sm_) 
 
 ### ARM, Ltd. **Integrator**
 
@@ -69,6 +70,62 @@
  * PrimeCell PL030 Real-time Clock in the System Controller FPGA (_plrtc_)
  * Other devices inserted into the PCI expansion slots
 
+### Atmark Techno **Armadillo-9**
+
+The Armadillo-9 is a single board computer based on the EP9315 processor.
+
+Support for the Armadillo-9 was written by Katsuomi Hamajima.
+
+ * On-CPU RS232 UARTs (2) (_epcom_)
+ * On-CPU 10/100 Ethernet MAC (_epe_)
+ * system clock from on-CPU timers (_epclk_)
+ * CompactFlash socket (_eppcic_)
+ * USB 1.1 ports (_ohci_)
+
+### BeagleBoard.org **BeagleBone**
+The [[BeagleBone]] is a low-cost credit-card-sized computer from BeagleBoard.
+
+### Gumstix, Inc. **gumstix**
+
+The [gumstix](http://www.gumstix.com/) is a small form-factor motherboard
+based on the PXA255 and PXA270 XScale processor. Supports only PXA255 now.
+
+Support for the gumstix was written by KIYOHARA Takashi.
+
+ * basix
+ * cfstix
+ * etherstix
+ * netCF
+ * netDUO
+ * netDUO-mmc
+ * netMMC 
+
+When booting, it is necessary to set these with u-boot dynamically.
+
+<pre> > go 0xa0200000 busheader=basix</pre>
+
+ * audiostix
+ * console-st (waysmall - STUART)
+ * console-hw (waysmall)
+ * GPSstix (GPS not test)
+ * tweener
+
+### Intel **DBPXA250** ("Lubbock") 
+
+DBPXA250 (a.k.a. Lubbock) is an evaluation and development platform for the
+Intel **PXA250** XScale Core application processor. More information about the **DBPXA250** can be found at [Intel website](http://www.intel.com/design/pca/applicationsprocessors/swsup/index.htm).
+
+Support for the **DBPXA250** was written by Hiroyuki Bessho, and contributed
+by Genetec Corp.
+
+ * On-chip timers (_saost_ used as system clock)
+ * On-chip 2 serial port (_com_)
+ * On-board SMC91C96 ethernet (_sm_)
+ * On-board SA-1111 StrongArm companion chip (_sacc_)
+ * PS/2 keyboard (_pckbd_)
+ * 640x480 LCD (_lcd_)
+ * PCMCIA and CF card slots
+
 ### Intel **IQ31244**
 
 The IQ31244 is a development platform for the Intel **IOP321** I/O Processor
@@ -115,22 +172,6 @@
  * On-chip watchdog timer (_iopwdog_)
  * Other devices inserted into the PCI-X expansion slots
 
-### Team ASA, Inc. **Npwr**
-
-The Npwr is an IOP310-based design targeted at the network-attached storage
-space. The Npwr comes in several configurations (single or dual Gigabit
-Ethernet, single or dual Ultra160 SCSI), and can be purchased as a bare board
-or as a small server appliance. More information on the Npwr can be found at
-the [Team ASA web page](http://www.teamasa.com/).
-
-Support for the Npwr was written by Jason Thorpe and Allen Briggs, and
-contributed by Wasabi Systems, Inc.
-
- * On-board Intel i82544 Gigabit Ethernet on the PCI bus (_wm_)
- * On-board LSI Logic 53c1010 Ultra160 SCSI on the PCI bus (_siop_)
- * On-board timer in the CPLD (used as system clock)
- * On-board NS16550-compatible serial port (_com_)
-
 ### Intel **IXM1200**
 
 The IXM1200 is the reference platform for the Intel **IXP1200** Network
@@ -143,6 +184,26 @@
  * On-chip timers (ixpclk0 used as system clock)
  * On-chip serial port (_ixpcom_)
 
+### NOVATEC **NTNP425B** ("ZAO425") 
+
+NTNP425B is an evaluation and development platform for the Intel **IXP425**
+XScale Core NetworkProcessor. NTNP425B is based on the reference board of
+Intel **IXDP425**. The **NTNP425B** is capable of only big-endian operation.
+Since the library for micro-engine(NPE) offered from Intel Corp. is big-
+endian. More information about the **NTNP425B** can be found on [product
+catalogue of **NTNP425B**(2.5MB,PDF
+file)](http://www.novatec.co.jp/NTNP425BBrochureE.pdf).
+
+Support for the NTNP425B was written by Ichiro FUKUHARA.
+
+ * On-chip timers (_ixpclk0_ used as system clock)
+ * On-chip 2 serial port (_ixpcom0_ and _ixpcom1_)
+ * Other devices inserted into the PCI/mPCI slot
+ * On-chip watchdog timer (_ixpwdog_)
+
+### Raspberry Pi Foundation **Raspberry Pi**
+The [[Raspberry Pi]] is a low-cost credit-card-sized computer from the Raspberry Pi Foundation.
+
 ### Samsung **SMDK2410**
 
 The SMDK2410 is the reference platform for the Samsung **S3C2410** processor,
@@ -177,108 +238,48 @@
  * On-chip timers (used as system clock)
  * Other devices inserted into the PCI slots 
 
-### ADI Engineering **BRH** ("Big Red Head") 
-
-The BRH is an evaluation and development platform for the Intel **i80200**
-XScale processor. The BRH is based on ADI's **BECC** ("Big Endian Companion
-Chip"). The BRH is capable of both big- and little-endian operation, although
-NetBSD currently only supports little-endian operation. More information about
-the BRH can be found on [ADI Engineering's web

(Diff truncated)
Add a TOC under the Supported Hardware heading
Index: wikisrc/ports/evbarm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/ports/evbarm.mdwn	20 Oct 2014 10:05:38 -0000	1.10
+++ wikisrc/ports/evbarm.mdwn	6 Nov 2014 16:40:19 -0000	1.11
@@ -15,6 +15,9 @@
 Matt Thomas is the maintainer of NetBSD/evbarm.
 """
 supported_hardware="""
+
+[[!toc startlevel=3]]
+
 ### Raspberry Pi Foundation **Raspberry Pi**
 The [[Raspberry Pi]] is a low-cost credit-card-sized computer from the Raspberry Pi Foundation.
 
@@ -283,4 +286,3 @@
 """
 ]]
 [[!tag tier1port]]
-

two more places in the website that need updating
Index: wikisrc/releng/release-prep.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng/release-prep.mdwn,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- wikisrc/releng/release-prep.mdwn	26 Sep 2014 03:58:38 -0000	1.15
+++ wikisrc/releng/release-prep.mdwn	5 Nov 2014 21:02:55 -0000	1.16
@@ -147,6 +147,8 @@
     - Commit release's HTML file in htdocs/releases/formal-&lt;blah&gt;
     - Update htdocs/share/xml/misc.ent (release.*)
     - Add htdocs/support/security/patches-&lt;blah&gt;
+    - Update htdocs/support/security/index.xml
+    - Update htdocs/support/security/release.xml
     - Update htdocs/releases/formal-&lt;blah&gt;/index.xml
     - Update htdocs/mirrors/torrents/
     - Update htdocs/releases/formal.xml

Make it bold instead of a headline.
Index: wikisrc/amazon_ec2/amis.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/amazon_ec2/amis.mdwn,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- wikisrc/amazon_ec2/amis.mdwn	5 Nov 2014 18:44:37 -0000	1.42
+++ wikisrc/amazon_ec2/amis.mdwn	5 Nov 2014 18:46:26 -0000	1.43
@@ -138,7 +138,7 @@
 
 The following AMIs are for 32-bit instances.
 
-### Note: eu-central-1 (Frankfurt) does not have instances capable of running 32-bit PV AMIs.
+*Note: eu-central-1 (Frankfurt) does not have instances capable of running 32-bit PV AMIs.*
 
 <table class="center">
 <tr>

Small text, not large
Index: wikisrc/amazon_ec2/amis.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/amazon_ec2/amis.mdwn,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- wikisrc/amazon_ec2/amis.mdwn	5 Nov 2014 18:43:43 -0000	1.41
+++ wikisrc/amazon_ec2/amis.mdwn	5 Nov 2014 18:44:37 -0000	1.42
@@ -138,7 +138,7 @@
 
 The following AMIs are for 32-bit instances.
 
-# Note: eu-central-1 (Frankfurt) does not have instances capable of running 32-bit PV AMIs.
+### Note: eu-central-1 (Frankfurt) does not have instances capable of running 32-bit PV AMIs.
 
 <table class="center">
 <tr>

Add 7.0_BETA amis, and a note about Frankfurt.
Index: wikisrc/amazon_ec2/amis.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/amazon_ec2/amis.mdwn,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- wikisrc/amazon_ec2/amis.mdwn	5 Nov 2014 17:55:47 -0000	1.40
+++ wikisrc/amazon_ec2/amis.mdwn	5 Nov 2014 18:43:43 -0000	1.41
@@ -120,12 +120,25 @@
   <td>ami-51e2d450</td><!-- ap-northeast-1 -->
   <td>ami-f1a511ec</td><!-- sa-east-1 -->
 </tr>
+<tr>
+  <th>NetBSD 7.0_BETA_201411041110Z</th>
+  <td>ami-848a04ec</td><!-- us-east-1 -->
+  <td>ami-25e4f360</td><!-- us-west-1 -->
+  <td>ami-f586cec5</td><!-- us-west-2 -->
+  <td>ami-72cdfb6f</td><!-- eu-central-1 -->
+  <td>ami-f44fe583</td><!-- eu-west-1 -->
+  <td>ami-945271c6</td><!-- ap-southeast-1 -->
+  <td>ami-996d02a3</td><!-- ap-southeast-2 -->
+  <td>ami-61a59a60</td><!-- ap-northeast-1 -->
+  <td>ami-c301b6de</td><!-- sa-east-1 -->
+</tr>
 </table>
 
 ## i386 -- 32 bit AMIs
 
 The following AMIs are for 32-bit instances.
 
+# Note: eu-central-1 (Frankfurt) does not have instances capable of running 32-bit PV AMIs.
 
 <table class="center">
 <tr>
@@ -133,7 +146,6 @@
   <th>us-east-1<br />(Virginia)</th>
   <th>us-west-1<br />(N. California)</th>
   <th>us-west-2<br />(Oregon)</th>
-  <th>eu-central-1<br />(Frankfurt)</th>
   <th>eu-west-1<br />(Ireland)</th>
   <th>ap-southeast-1<br />(Singapore)</th>
   <th>ap-southeast-2<br />(Sydney)</th>
@@ -145,7 +157,6 @@
   <td>ami-0d82bf64</td><!-- us-east-1 -->
   <td>ami-50c8fa15</td><!-- us-west-1 -->
   <td>ami-7e1a7a4e</td><!-- us-west-2 -->
-  <td>-</td><!-- eu-central-1 -->
   <td>ami-206a9e57</td><!-- eu-west-1 -->
   <td>ami-223e6870</td><!-- ap-southeast-1 -->
   <td>ami-b95fc183</td><!-- ap-southeast-2 -->
@@ -157,7 +168,6 @@
   <td>ami-3583be5c</td><!-- us-east-1 -->
   <td>ami-cccefc89</td><!-- us-west-1 -->
   <td>ami-fa1979ca</td><!-- us-west-2 -->
-  <td>-</td><!-- eu-central-1 -->
   <td>ami-ca699dbd</td><!-- eu-west-1 -->
   <td>ami-1a3e6848</td><!-- ap-southeast-1 -->
   <td>ami-4f5fc175</td><!-- ap-southeast-2 -->
@@ -169,7 +179,6 @@
   <td>ami-8b87bae2</td><!-- us-east-1 -->
   <td>ami-30cbf975</td><!-- us-west-1 -->
   <td>ami-7c19794c</td><!-- us-west-2 -->
-  <td>-</td><!-- eu-central-1 -->
   <td>ami-14689c63</td><!-- eu-west-1 -->
   <td>ami-ac3167fe</td><!-- ap-southeast-1 -->
   <td>ami-6f5fc155</td><!-- ap-southeast-2 -->
@@ -181,7 +190,6 @@
   <td>ami-fd2f3794</td><!-- us-east-1 -->
   <td>ami-da2b139f</td><!-- us-west-1 -->
   <td>ami-e42d58d4</td><!-- us-west-2 -->
-  <td>-</td><!-- eu-central-1 -->
   <td>ami-ad9550da</td><!-- eu-west-1 -->
   <td>ami-02613250</td><!-- ap-southeast-1 -->
   <td>ami-450b937f</td><!-- ap-southeast-2 -->
@@ -193,7 +201,6 @@
   <td>ami-62249c0a</td><!-- us-east-1 -->
   <td>ami-7945503c</td><!-- us-west-1 -->
   <td>ami-ede2aedd</td><!-- us-west-2 -->
-  <td>-</td><!-- eu-central-1 -->
   <td>ami-302e8247</td><!-- eu-west-1 -->
   <td>ami-3498be66</td><!-- ap-southeast-1 -->
   <td>ami-1d432e27</td><!-- ap-southeast-2 -->
@@ -205,7 +212,6 @@
   <td>ami-a185b8c8</td><!-- us-east-1 -->
   <td>ami-e4cefca1</td><!-- us-west-1 -->
   <td>ami-50187860</td><!-- us-west-2 -->
-  <td>-</td><!-- eu-central-1 -->
   <td>ami-7e689c09</td><!-- eu-west-1 -->
   <td>ami-fa3167a8</td><!-- ap-southeast-1 -->
   <td>ami-1f5fc125</td><!-- ap-southeast-2 -->
@@ -217,7 +223,6 @@
   <td>ami-cd2b33a4</td><!-- us-east-1 -->
   <td>ami-6c2b1329</td><!-- us-west-1 -->
   <td>ami-fc2257cc</td><!-- us-west-2 -->
-  <td>-</td><!-- eu-central-1 -->
   <td>ami-294fb55e</td><!-- eu-west-1 -->
   <td>ami-be7e2dec</td><!-- ap-southeast-1 -->
   <td>ami-7d089047</td><!-- ap-southeast-2 -->
@@ -229,11 +234,21 @@
   <td>ami-b618a0de</td><!-- us-east-1 -->
   <td>ami-3d5a4f78</td><!-- us-west-1 -->
   <td>ami-3be2ae0b</td><!-- us-west-2 -->
-  <td>-</td><!-- eu-central-1 -->
   <td>ami-aa2c80dd</td><!-- eu-west-1 -->
   <td>ami-5a98be08</td><!-- ap-southeast-1 -->
   <td>ami-fd402dc7</td><!-- ap-southeast-2 -->
   <td>ami-3befd93a</td><!-- ap-northeast-1 -->
   <td>ami-07a6121a</td><!-- sa-east-1 -->
 </tr>
+<tr>
+  <th>NetBSD 7.0_BETA_201411041110Z</th>
+  <td>ami-a28d03ca</td><!-- us-east-1 -->
+  <td>ami-73e4f336</td><!-- us-west-1 -->
+  <td>ami-5587cf65</td><!-- us-west-2 -->
+  <td>ami-184ee46f</td><!-- eu-west-1 -->
+  <td>ami-24527176</td><!-- ap-southeast-1 -->
+  <td>ami-5f6d0265</td><!-- ap-southeast-2 -->
+  <td>ami-efa699ee</td><!-- ap-northeast-1 -->
+  <td>ami-3101b62c</td><!-- sa-east-1 -->
+</tr>
 </table>

Make space for Frankfurt.
Index: wikisrc/amazon_ec2/amis.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/amazon_ec2/amis.mdwn,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- wikisrc/amazon_ec2/amis.mdwn	15 Oct 2014 23:50:58 -0000	1.39
+++ wikisrc/amazon_ec2/amis.mdwn	5 Nov 2014 17:55:47 -0000	1.40
@@ -17,6 +17,7 @@
   <th>us-east-1<br />(Virginia)</th>
   <th>us-west-1<br />(N. California)</th>
   <th>us-west-2<br />(Oregon)</th>
+  <th>eu-central-1<br />(Frankfurt)</th>
   <th>eu-west-1<br />(Ireland)</th>
   <th>ap-southeast-1<br />(Singapore)</th>
   <th>ap-southeast-2<br />(Sydney)</th>
@@ -28,6 +29,7 @@
   <td>ami-738eb31a</td><!-- us-east-1 -->
   <td>ami-8cc5f7c9</td><!-- us-west-1 -->
   <td>ami-6e16765e</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-226e9a55</td><!-- eu-west-1 -->
   <td>ami-4e31671c</td><!-- ap-southeast-1 -->
   <td>ami-815ec0bb</td><!-- ap-southeast-2 -->
@@ -39,6 +41,7 @@
   <td>ami-198cb170</td><!-- us-east-1 -->
   <td>ami-20c5f765</td><!-- us-west-1 -->
   <td>ami-841575b4</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-106d9967</td><!-- eu-west-1 -->
   <td>ami-643f6936</td><!-- ap-southeast-1 -->
   <td>ami-b15ec08b</td><!-- ap-southeast-2 -->
@@ -50,6 +53,7 @@
   <td>ami-e192af88</td><!-- us-east-1 -->
   <td>ami-5cc5f719</td><!-- us-west-1 -->
   <td>ami-48157578</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-6c6d991b</td><!-- eu-west-1 -->
   <td>ami-0830665a</td><!-- ap-southeast-1 -->
   <td>ami-695ec053</td><!-- ap-southeast-2 -->
@@ -61,6 +65,7 @@
   <td>ami-45465e2c</td><!-- us-east-1 -->
   <td>ami-22300867</td><!-- us-west-1 -->
   <td>ami-883643b8</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-154bb162</td><!-- eu-west-1 -->
   <td>ami-c47f2c96</td><!-- ap-southeast-1 -->
   <td>ami-3108900b</td><!-- ap-southeast-2 -->
@@ -72,6 +77,7 @@
   <td>ami-ee229a86</td><!-- us-east-1 -->
   <td>ami-ab5a4fee</td><!-- us-west-1 -->
   <td>ami-43e2ae73</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-c62d81b1</td><!-- eu-west-1 -->
   <td>ami-6e98be3c</td><!-- ap-southeast-1 -->
   <td>ami-c3402df9</td><!-- ap-southeast-2 -->
@@ -83,6 +89,7 @@
   <td>ami-1d90ad74</td><!-- us-east-1 -->
   <td>ami-aea092eb</td><!-- us-west-1 -->
   <td>ami-30076700</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-6a7d891d</td><!-- eu-west-1 -->
   <td>ami-dc34628e</td><!-- ap-southeast-1 -->
   <td>ami-a1a33d9b</td><!-- ap-southeast-2 -->
@@ -94,6 +101,7 @@
   <td>ami-87435bee</td><!-- us-east-1 -->
   <td>ami-223e0667</td><!-- us-west-1 -->
   <td>ami-26344116</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-6b55af1c</td><!-- eu-west-1 -->
   <td>ami-7e7f2c2c</td><!-- ap-southeast-1 -->
   <td>ami-fb178fc1</td><!-- ap-southeast-2 -->
@@ -105,6 +113,7 @@
   <td>ami-bc2c94d4</td><!-- us-east-1 -->
   <td>ami-415a4f04</td><!-- us-west-1 -->
   <td>ami-6ffbb75f</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-f253ff85</td><!-- eu-west-1 -->
   <td>ami-989bbdca</td><!-- ap-southeast-1 -->
   <td>ami-63402d59</td><!-- ap-southeast-2 -->
@@ -124,6 +133,7 @@
   <th>us-east-1<br />(Virginia)</th>
   <th>us-west-1<br />(N. California)</th>
   <th>us-west-2<br />(Oregon)</th>
+  <th>eu-central-1<br />(Frankfurt)</th>
   <th>eu-west-1<br />(Ireland)</th>
   <th>ap-southeast-1<br />(Singapore)</th>
   <th>ap-southeast-2<br />(Sydney)</th>
@@ -135,6 +145,7 @@
   <td>ami-0d82bf64</td><!-- us-east-1 -->
   <td>ami-50c8fa15</td><!-- us-west-1 -->
   <td>ami-7e1a7a4e</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-206a9e57</td><!-- eu-west-1 -->
   <td>ami-223e6870</td><!-- ap-southeast-1 -->
   <td>ami-b95fc183</td><!-- ap-southeast-2 -->
@@ -146,6 +157,7 @@
   <td>ami-3583be5c</td><!-- us-east-1 -->
   <td>ami-cccefc89</td><!-- us-west-1 -->
   <td>ami-fa1979ca</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-ca699dbd</td><!-- eu-west-1 -->
   <td>ami-1a3e6848</td><!-- ap-southeast-1 -->
   <td>ami-4f5fc175</td><!-- ap-southeast-2 -->
@@ -157,6 +169,7 @@
   <td>ami-8b87bae2</td><!-- us-east-1 -->
   <td>ami-30cbf975</td><!-- us-west-1 -->
   <td>ami-7c19794c</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-14689c63</td><!-- eu-west-1 -->
   <td>ami-ac3167fe</td><!-- ap-southeast-1 -->
   <td>ami-6f5fc155</td><!-- ap-southeast-2 -->
@@ -168,6 +181,7 @@
   <td>ami-fd2f3794</td><!-- us-east-1 -->
   <td>ami-da2b139f</td><!-- us-west-1 -->
   <td>ami-e42d58d4</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-ad9550da</td><!-- eu-west-1 -->
   <td>ami-02613250</td><!-- ap-southeast-1 -->
   <td>ami-450b937f</td><!-- ap-southeast-2 -->
@@ -179,6 +193,7 @@
   <td>ami-62249c0a</td><!-- us-east-1 -->
   <td>ami-7945503c</td><!-- us-west-1 -->
   <td>ami-ede2aedd</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-302e8247</td><!-- eu-west-1 -->
   <td>ami-3498be66</td><!-- ap-southeast-1 -->
   <td>ami-1d432e27</td><!-- ap-southeast-2 -->
@@ -190,6 +205,7 @@
   <td>ami-a185b8c8</td><!-- us-east-1 -->
   <td>ami-e4cefca1</td><!-- us-west-1 -->
   <td>ami-50187860</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-7e689c09</td><!-- eu-west-1 -->
   <td>ami-fa3167a8</td><!-- ap-southeast-1 -->
   <td>ami-1f5fc125</td><!-- ap-southeast-2 -->
@@ -201,6 +217,7 @@
   <td>ami-cd2b33a4</td><!-- us-east-1 -->
   <td>ami-6c2b1329</td><!-- us-west-1 -->
   <td>ami-fc2257cc</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-294fb55e</td><!-- eu-west-1 -->
   <td>ami-be7e2dec</td><!-- ap-southeast-1 -->
   <td>ami-7d089047</td><!-- ap-southeast-2 -->
@@ -212,6 +229,7 @@
   <td>ami-b618a0de</td><!-- us-east-1 -->
   <td>ami-3d5a4f78</td><!-- us-west-1 -->
   <td>ami-3be2ae0b</td><!-- us-west-2 -->
+  <td>-</td><!-- eu-central-1 -->
   <td>ami-aa2c80dd</td><!-- eu-west-1 -->
   <td>ami-5a98be08</td><!-- ap-southeast-1 -->
   <td>ami-fd402dc7</td><!-- ap-southeast-2 -->

MULTIPROCESSOR works now
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- wikisrc/ports/evbarm/allwinner.mdwn	30 Oct 2014 00:34:52 -0000	1.22
+++ wikisrc/ports/evbarm/allwinner.mdwn	5 Nov 2014 01:22:36 -0000	1.23
@@ -11,7 +11,7 @@
 # Supported hardware
  - SoCs
    - Cortex-A8: A10
-   - Cortex-A7: A20, A31
+   - Cortex-A7: A20 (2-core), A31 (4-core)
  - SD/MMC controller (DMA)
  - DMA controller
  - GPIO
@@ -33,7 +33,6 @@
  - Gigabit Ethernet (GMAC)
 
 # TODO
- - MULTIPROCESSOR is not yet stable
  - HDMI (some work completed here for A20)
  - Framebuffer
  - OTG (A31)

update current releases
Index: wikisrc/releng.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/releng.mdwn	26 Sep 2014 03:54:20 -0000	1.11
+++ wikisrc/releng.mdwn	4 Nov 2014 05:59:20 -0000	1.12
@@ -21,9 +21,9 @@
 * Next Minor Release: NetBSD 6.2 (No release date proposed)
   + CVS branch tag: <code>netbsd-6</code>
 * Actively supported teeny releases:
-  + [NetBSD 6.1.4](http://www.netbsd.org/releases/formal-6/NetBSD-6.1.4.html)
+  + [NetBSD 6.1.5](http://www.netbsd.org/releases/formal-6/NetBSD-6.1.5.html)
     - CVS branch tag: <code>netbsd-6-1</code>
-  + [NetBSD 6.0.5](http://www.netbsd.org/releases/formal-6/NetBSD-6.0.5.html)
+  + [NetBSD 6.0.6](http://www.netbsd.org/releases/formal-6/NetBSD-6.0.6.html)
     - CVS branch tag: <code>netbsd-6-0</code>
 * [Current pull-up queue for the netbsd-6 branch](http://releng.netbsd.org/cgi-bin/req-6.cgi)
 

Note location of pre-compiled fex bins.
Index: wikisrc/ports/evbarm/allwinner.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/evbarm/allwinner.mdwn,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- wikisrc/ports/evbarm/allwinner.mdwn	22 Oct 2014 00:43:23 -0000	1.21
+++ wikisrc/ports/evbarm/allwinner.mdwn	30 Oct 2014 00:34:52 -0000	1.22
@@ -89,6 +89,8 @@
 uenvcmd=mmc dev 0; mmc rescan; fatload mmc 0:1 43000000 cubieboard2.bin; fatload mmc 0:1 82000000 netbsd.ub; bootm 82000000
 """]]
 
+Some pre-compiled .bin files can be found here: <http://ftp.netbsd.org/pub/NetBSD/misc/jmcneill/allwinner/fex/>
+
 # Board specific notes
 
 ## Merrii Hummingbird A31

u
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:25:37 -0000	1.19
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:26:59 -0000	1.20
@@ -526,7 +526,6 @@
     % sudo drvctl -a ata_hl -r atabus4
     % sudo raidctl -c raid0.conf raid0
     % sudo mount NAME=stripes /mnt
-    % sudo mount NAME=stripes /mnt
     % df -h /mnt
     Filesystem         Size       Used      Avail %Cap Mounted on
     /dev/dk10           11T       1.0G        10T   0% /mnt

u
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:24:46 -0000	1.18
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:25:37 -0000	1.19
@@ -536,5 +536,6 @@
 
 Unlike wedges, the raidframe devices are not automatically created when a disk attaches.
 That's why we needed the raidctl -c command. The raidframe driver however scans all disks
-available when booting and creates devices for all raidsets found.
+available when booting and autoconfigures devices for all raidsets found that have the
+autoconfig flag set.
 

u
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:23:28 -0000	1.17
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:24:46 -0000	1.18
@@ -513,7 +513,7 @@
     ** File system is clean; not checking
 </code></pre>
 
-Older versions of newfs do not support wedgenames, you need to
+Older versions of fsck do not support wedgenames, you need to
 specify the device, e.g. /dev/rdk10.
 
 ## and more

u
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:21:50 -0000	1.16
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:23:28 -0000	1.17
@@ -341,10 +341,10 @@
     
     4 partitions:
     #        size    offset     fstype [fsize bsize cpg/sgs]
-     a: 4294967295         0     4.2BSD      0     0     0  # (Cyl.      0 - 4294967295*)
-      d: 4294967295         0     unused      0     0        # (Cyl.      0 - 4294967295*)
-      disklabel: boot block size 0
-      disklabel: super block size 0
+    a: 4294967295         0     4.2BSD      0     0     0  # (Cyl.      0 - 4294967295*)
+    d: 4294967295         0     unused      0     0        # (Cyl.      0 - 4294967295*)
+    disklabel: boot block size 0
+    disklabel: super block size 0
 </code></pre>
 
 ## using
@@ -462,8 +462,8 @@
     
     4 partitions:
     #        size    offset     fstype [fsize bsize cpg/sgs]
-     a: 4294967295         0     4.2BSD      0     0     0  # (Cyl.      0 - 4294967295*)
-     d: 4294967295         0     unused      0     0        # (Cyl.      0 - 4294967295*)
+    a: 4294967295         0     4.2BSD      0     0     0  # (Cyl.      0 - 4294967295*)
+    d: 4294967295         0     unused      0     0        # (Cyl.      0 - 4294967295*)
     disklabel: boot block size 0
     disklabel: super block size 0
     % sudo dkctl raid0 listwedges

u
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:12:14 -0000	1.15
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:21:50 -0000	1.16
@@ -251,7 +251,7 @@
       11721044992          143         
       11721045135           32         Sec GPT table
       11721045167            1         Sec GPT header
-</code><pre>
+</code></pre>
 
 Since wedges are currently only created when a device is attached, we
 need either a reboot or some magic using drvctl.
@@ -260,7 +260,7 @@
     % sudo drvctl -d wd2
     % sudo drvctl -a ata_hl -r atabus3
     % sudo drvctl -a ata_hl -r atabus4
-</code><pre>
+</code></pre>
 
 The console or dmesg will reveal that both disks have been reattached
 and wedges have been created:
@@ -283,7 +283,7 @@
     dk6: 11721043968 blocks at 1024, type: ccd
     wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
     wd2(ahcisata0:2:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA)
-</code><pre>
+</code></pre>
 
 # CCD
 
@@ -296,7 +296,7 @@
 <pre><code>
    % sudo ccdconfig -c ccd0 16 none NAME=hugedisk1 NAME=hugedisk2
    ccdconfig: NAME=hugedisk1: No such file or directory
-</code><pre>
+</code></pre>
 
 This cannot easily be handled, because the NAME= syntax exists in userland.
 All tools that understand it, translate the wedge name into a device path.
@@ -313,7 +313,7 @@
 the disklabel from the first component.
 <pre><code>
    % sudo ccdconfig -u ccd0
-</code><pre>
+</code></pre>
 
 ## configuring
 For now we use the wedge device directly.
@@ -345,7 +345,7 @@
       d: 4294967295         0     unused      0     0        # (Cyl.      0 - 4294967295*)
       disklabel: boot block size 0
       disklabel: super block size 0
-</code><pre>
+</code></pre>
 
 ## using
 Obviously the device that spans two disks is also too large for disklabel.
@@ -353,7 +353,7 @@
 <pre><code>
     % sudo dkctl ccd0 listwedges
     dkctl: /dev/rccd0d: listwedges: Inappropriate ioctl for device
-</code><pre>
+</code></pre>
 
 The ccd driver does not support wedges at all. But we can still use
 the raw partition.
@@ -370,7 +370,7 @@
     /dev/ccd0d          11T       4.0K        10T   0% /mnt
     % sudo umount /mnt
     % sudo ccdconfig -u ccd0
-</code><pre>
+</code></pre>
 
 # Raidframe
 Since ccd wasn't that good, lets create a RAID0 using the raidframe driver.
@@ -401,7 +401,7 @@
   11721044992          143         
   11721045135           32         Sec GPT table
   11721045167            1         Sec GPT header
-</code><pre>
+</code></pre>
 
 And the reattachment magic:
 <pre><code>
@@ -415,7 +415,7 @@
     % sudo dkctl wd2 listwedges
     /dev/rwd2d: 1 wedge:
     dk6: hugedisk2, 11721043968 blocks at 1024, type: raidframe
-</code><pre>
+</code></pre>
 
 ## configuring
 For raidframe we need a configuration file:
@@ -468,7 +468,7 @@
     disklabel: super block size 0
     % sudo dkctl raid0 listwedges
     /dev/rraid0d: no wedges configured
-</code><pre>
+</code></pre>
 
 ## formatting
 The raidframe driver has no problems with wedges. We can create a GPT
@@ -503,7 +503,7 @@
     1000+0 records out
     1048576000 bytes transferred in 4.961 secs (211363837 bytes/sec)
     % sudo umount /mnt
-</code><pre>
+</code></pre>
 
 ## checking
 And also be checked.
@@ -511,7 +511,7 @@
     % sudo fsck NAME=stripes
     ** /dev/rdk10
     ** File system is clean; not checking
-</code><pre>
+</code></pre>
 
 Older versions of newfs do not support wedgenames, you need to
 specify the device, e.g. /dev/rdk10.
@@ -532,7 +532,7 @@
     /dev/dk10           11T       1.0G        10T   0% /mnt
     % ls -l /mnt/scratch/testfile
     -rw-r--r--  1 mlelstv  wheel  1048576000 Oct 25 21:47 /mnt/scratch/testfile
-</code><pre>
+</code></pre>
 
 Unlike wedges, the raidframe devices are not automatically created when a disk attaches.
 That's why we needed the raidctl -c command. The raidframe driver however scans all disks

u
Index: wikisrc/users/mlelstv.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv.mdwn,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- wikisrc/users/mlelstv.mdwn	23 Sep 2014 09:19:16 -0000	1.17
+++ wikisrc/users/mlelstv.mdwn	25 Oct 2014 22:15:45 -0000	1.18
@@ -4,6 +4,7 @@
 - [[Device naming, the first|mlelstv/device-naming]]
 - [[Device naming, the second|mlelstv/device-naming2]]
 - [[Disk interfaces in the kernel|mlelstv/disk-devices-layered]]
+- [[Using large disks|mlelstv/using-large-disks]]
 
 # 2
 - [[Supported video|mlelstv/supported-video]]

u
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:10:53 -0000	1.14
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:12:14 -0000	1.15
@@ -508,9 +508,9 @@
 ## checking
 And also be checked.
 <pre><code>
-% sudo fsck NAME=stripes
-** /dev/rdk10
-** File system is clean; not checking
+    % sudo fsck NAME=stripes
+    ** /dev/rdk10
+    ** File system is clean; not checking
 </code><pre>
 
 Older versions of newfs do not support wedgenames, you need to

u
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:10:14 -0000	1.13
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:10:53 -0000	1.14
@@ -315,7 +315,7 @@
    % sudo ccdconfig -u ccd0
 </code><pre>
 
-# configuring
+## configuring
 For now we use the wedge device directly.
 <pre><code>
     % sudo ccdconfig -c ccd0 16 none /dev/dk5 /dev/dk6
@@ -347,7 +347,7 @@
       disklabel: super block size 0
 </code><pre>
 
-# using
+## using
 Obviously the device that spans two disks is also too large for disklabel.
 What about wedges?
 <pre><code>

u
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:09:34 -0000	1.12
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:10:14 -0000	1.13
@@ -27,7 +27,7 @@
 The NetBSD kernel seems to recgonize the disk size fine. But when running
 the disklabel program to partition the disk, you get this:
 <pre><code>
-    pussyfoot: {%} disklabel wd1
+    % disklabel wd1
     # /dev/rwd1d:
     type: ESDI
     disk: WDC WD60EFRX-68M
@@ -77,14 +77,14 @@
 
 ## formatting
 <pre><code>
-    pussyfoot: {%} sudo newfs /dev/rwd1d
+    % sudo newfs /dev/rwd1d
     newfs: /dev/rwd1d partition type is not `4.2BSD'
 </code></pre>
 
 The raw partition has no correct type and newfs refuses to work, we
 have to persuade it a little bit:
 <pre><code>
-    pussyfoot: {%} sudo newfs -O2 -F -s 11721045168 /dev/rwd1d
+    % sudo newfs -O2 -F -s 11721045168 /dev/rwd1d
     /dev/rwd1d: 5723166.5MB (11721045168 sectors) block size 32768, fragment size 4096
             using 7710 cylinder groups of 742.31MB, 23754 blks, 46848 inodes.
     super-block backups (for fsck_ffs -b #) at:
@@ -98,34 +98,34 @@
 ## using
 Then we can mount and use the disk:
 <pre><code>
-    pussyfoot: {%} sudo mount /dev/wd1d /mnt
-    pussyfoot: {%} sudo mkdir -m 1777 /mnt/scratch
-    pussyfoot: {%} dd if=/dev/zero bs=1024k count=1000 of=/mnt/scratch/testfile
+    % sudo mount /dev/wd1d /mnt
+    % sudo mkdir -m 1777 /mnt/scratch
+    % dd if=/dev/zero bs=1024k count=1000 of=/mnt/scratch/testfile
     1000+0 records in
     1000+0 records out
     1048576000 bytes transferred in 10.350 secs (101311690 bytes/sec)
-    pussyfoot: {%} ls -la /mnt/scratch/
+    % ls -la /mnt/scratch/
     total 2048592
     drwxrwxrwt  2 root     wheel         512 Oct 25 17:34 .
     drwxr-xr-x  3 root     wheel         512 Oct 25 17:34 ..
     -rw-r--r--  1 mlelstv  wheel  1048576000 Oct 25 17:35 testfile
-    pussyfoot: {%} sudo umount /mnt
+    % sudo umount /mnt
 </code></pre>
 
 ## checking
 Filesystem checking needs extra effort:
 <pre><code>
-    pussyfoot: {%} sudo fsck /dev/rwd1d
+    % sudo fsck /dev/rwd1d
     fsck: vfstype `unused' on partition `/dev/rwd1d' is not supported
 </code></pre>
 
 Again you need to augment information from the disklabel for the raw
 partition:
 <pre><code>
-    pussyfoot: {%} sudo fsck -t ffs /dev/rwd1d
+    % sudo fsck -t ffs /dev/rwd1d
     ** /dev/rwd1d
     ** File system is clean; not checking
-    pussyfoot: {%} sudo fsck -t ffs -f /dev/rwd1d
+    % sudo fsck -t ffs -f /dev/rwd1d
     ** /dev/rwd1d
     ** File system is already clean
     ** Last Mounted on /mnt
@@ -164,7 +164,7 @@
 
 Here is a disk with a wedge:
 <pre><code>
-    pussyfoot: {%} sudo dkctl wd2 listwedges
+    % sudo dkctl wd2 listwedges
     /dev/rwd2d: 1 wedge:
     dk6: hugedisk2, 11721043968 blocks at 1024, type: ccd
 </code></pre>
@@ -173,15 +173,15 @@
 by specifying a name, start offset on the disk, the wedge size and
 a type.
 <pre><code>
-    pussyfoot: {%} sudo dkctl wd2 addwedge testwedge 34 500 ffs
+    % sudo dkctl wd2 addwedge testwedge 34 500 ffs
     dk5 created successfully.
-    pussyfoot: {%} sudo dkctl wd2 addwedge testwedge 500 100 unused
+    % sudo dkctl wd2 addwedge testwedge 500 100 unused
     dkctl: /dev/rwd2d: addwedge: Invalid argument
-    pussyfoot: {%} sudo dkctl wd2 addwedge testwedge 534 100 unused
+    % sudo dkctl wd2 addwedge testwedge 534 100 unused
     dkctl: /dev/rwd2d: addwedge: File exists
-    pussyfoot: {%} sudo dkctl wd2 addwedge testwedge2 534 100 unused
+    % sudo dkctl wd2 addwedge testwedge2 534 100 unused
     dk10 created successfully.
-    pussyfoot: {%} sudo dkctl wd2 listwedges
+    % sudo dkctl wd2 listwedges
     /dev/rwd2d: 3 wedges:
     dk5: testwedge, 500 blocks at 34, type: ffs
     dk10: testwedge2, 100 blocks at 534, type: unused
@@ -191,7 +191,7 @@
 You can see that creation of a wedge is validated, it requires a unique
 name and the wedges must not overlap.
 <pre><code>
-    pussyfoot: {%} sudo newfs NAME=testwedge
+    % sudo newfs NAME=testwedge
     /dev/rdk5: 0.2MB (500 sectors) block size 4096, fragment size 512
             using 3 cylinder groups of 0.08MB, 21 blks, 32 inodes.
 	    super-block backups (for fsck_ffs -b #) at:
@@ -212,7 +212,7 @@
 
 A GPT can be displayed, created and edited with the GPT command:
 <pre><code>
-    pussyfoot: {%} sudo gpt show wd2
+    % sudo gpt show wd2
             start         size  index  contents
                 0            1         PMBR
                 1            1         Pri GPT header
@@ -222,14 +222,14 @@
       11721044992          143         
       11721045135           32         Sec GPT table
       11721045167            1         Sec GPT header
-    pussyfoot: {%} sudo gpt show wd1
+    % sudo gpt show wd1
             start         size  index  contents
                 0  11721045168         
-    pussyfoot: {%} sudo gpt show wd1
+    % sudo gpt show wd1
             start         size  index  contents
                 0  11721045168         
-    pussyfoot: {%} sudo gpt create wd1
-    pussyfoot: {%} sudo gpt show wd1
+    % sudo gpt create wd1
+    % sudo gpt show wd1
             start         size  index  contents
                 0            1         PMBR
                 1            1         Pri GPT header
@@ -237,11 +237,11 @@
                34  11721045101         
       11721045135           32         Sec GPT table
       11721045167            1         Sec GPT header
-    pussyfoot: {%} sudo gpt add -a 512k -l hugedisk1 -t ccd wd1
+    % sudo gpt add -a 512k -l hugedisk1 -t ccd wd1
     Partition 1 added, use:
             dkctl wd1 addwedge <wedgename> 1024 11721043968 <type>
     to create a wedge for it
-    pussyfoot: {%} sudo gpt show wd1
+    % sudo gpt show wd1
             start         size  index  contents
                 0            1         PMBR
                 1            1         Pri GPT header
@@ -256,10 +256,10 @@
 Since wedges are currently only created when a device is attached, we
 need either a reboot or some magic using drvctl.
 <pre><code>
-    pussyfoot: {%} sudo drvctl -d wd1
-    pussyfoot: {%} sudo drvctl -d wd2
-    pussyfoot: {%} sudo drvctl -a ata_hl -r atabus3
-    pussyfoot: {%} sudo drvctl -a ata_hl -r atabus4
+    % sudo drvctl -d wd1
+    % sudo drvctl -d wd2
+    % sudo drvctl -a ata_hl -r atabus3
+    % sudo drvctl -a ata_hl -r atabus4
 </code><pre>
 
 The console or dmesg will reveal that both disks have been reattached
@@ -294,7 +294,7 @@
 ccd is a very old driver and has some deficiencies. For one, the ccdconfig
 tool doesn't understand wedge names.
 <pre><code>
-   pussyfoot: {%} sudo ccdconfig -c ccd0 16 none NAME=hugedisk1 NAME=hugedisk2
+   % sudo ccdconfig -c ccd0 16 none NAME=hugedisk1 NAME=hugedisk2
    ccdconfig: NAME=hugedisk1: No such file or directory
 </code><pre>
 
@@ -312,14 +312,14 @@
 needs to be removed again. The warning comes from the attempt to read
 the disklabel from the first component.
 <pre><code>
-   pussyfoot: {%} sudo ccdconfig -u ccd0
+   % sudo ccdconfig -u ccd0
 </code><pre>
 
 # configuring
 For now we use the wedge device directly.
 <pre><code>
-    pussyfoot: {%} sudo ccdconfig -c ccd0 16 none /dev/dk5 /dev/dk6
-    pussyfoot: {%} disklabel ccd0
+    % sudo ccdconfig -c ccd0 16 none /dev/dk5 /dev/dk6
+    % disklabel ccd0
     # /dev/rccd0d:
     type: ccd
     disk: ccd

(Diff truncated)
r
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 21:25:51 -0000	1.11
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 22:09:34 -0000	1.12
@@ -27,7 +27,7 @@
 The NetBSD kernel seems to recgonize the disk size fine. But when running
 the disklabel program to partition the disk, you get this:
 <pre><code>
-    pussyfoot: {1} disklabel wd1
+    pussyfoot: {%} disklabel wd1
     # /dev/rwd1d:
     type: ESDI
     disk: WDC WD60EFRX-68M
@@ -77,14 +77,14 @@
 
 ## formatting
 <pre><code>
-    pussyfoot: {42} sudo newfs /dev/rwd1d
+    pussyfoot: {%} sudo newfs /dev/rwd1d
     newfs: /dev/rwd1d partition type is not `4.2BSD'
 </code></pre>
 
 The raw partition has no correct type and newfs refuses to work, we
 have to persuade it a little bit:
 <pre><code>
-    pussyfoot: {45} sudo newfs -O2 -F -s 11721045168 /dev/rwd1d
+    pussyfoot: {%} sudo newfs -O2 -F -s 11721045168 /dev/rwd1d
     /dev/rwd1d: 5723166.5MB (11721045168 sectors) block size 32768, fragment size 4096
             using 7710 cylinder groups of 742.31MB, 23754 blks, 46848 inodes.
     super-block backups (for fsck_ffs -b #) at:
@@ -98,34 +98,34 @@
 ## using
 Then we can mount and use the disk:
 <pre><code>
-    pussyfoot: {47} sudo mount /dev/wd1d /mnt
-    pussyfoot: {48} sudo mkdir -m 1777 /mnt/scratch
-    pussyfoot: {49} dd if=/dev/zero bs=1024k count=1000 of=/mnt/scratch/testfile
+    pussyfoot: {%} sudo mount /dev/wd1d /mnt
+    pussyfoot: {%} sudo mkdir -m 1777 /mnt/scratch
+    pussyfoot: {%} dd if=/dev/zero bs=1024k count=1000 of=/mnt/scratch/testfile
     1000+0 records in
     1000+0 records out
     1048576000 bytes transferred in 10.350 secs (101311690 bytes/sec)
-    pussyfoot: {50} ls -la /mnt/scratch/
+    pussyfoot: {%} ls -la /mnt/scratch/
     total 2048592
     drwxrwxrwt  2 root     wheel         512 Oct 25 17:34 .
     drwxr-xr-x  3 root     wheel         512 Oct 25 17:34 ..
     -rw-r--r--  1 mlelstv  wheel  1048576000 Oct 25 17:35 testfile
-    pussyfoot: {51} sudo umount /mnt
+    pussyfoot: {%} sudo umount /mnt
 </code></pre>
 
 ## checking
 Filesystem checking needs extra effort:
 <pre><code>
-    pussyfoot: {58} sudo fsck /dev/rwd1d
+    pussyfoot: {%} sudo fsck /dev/rwd1d
     fsck: vfstype `unused' on partition `/dev/rwd1d' is not supported
 </code></pre>
 
 Again you need to augment information from the disklabel for the raw
 partition:
 <pre><code>
-    pussyfoot: {57} sudo fsck -t ffs /dev/rwd1d
+    pussyfoot: {%} sudo fsck -t ffs /dev/rwd1d
     ** /dev/rwd1d
     ** File system is clean; not checking
-    pussyfoot: {60} sudo fsck -t ffs -f /dev/rwd1d
+    pussyfoot: {%} sudo fsck -t ffs -f /dev/rwd1d
     ** /dev/rwd1d
     ** File system is already clean
     ** Last Mounted on /mnt
@@ -164,7 +164,7 @@
 
 Here is a disk with a wedge:
 <pre><code>
-    pussyfoot: {100} sudo dkctl wd2 listwedges
+    pussyfoot: {%} sudo dkctl wd2 listwedges
     /dev/rwd2d: 1 wedge:
     dk6: hugedisk2, 11721043968 blocks at 1024, type: ccd
 </code></pre>
@@ -173,15 +173,15 @@
 by specifying a name, start offset on the disk, the wedge size and
 a type.
 <pre><code>
-    pussyfoot: {103} sudo dkctl wd2 addwedge testwedge 34 500 ffs
+    pussyfoot: {%} sudo dkctl wd2 addwedge testwedge 34 500 ffs
     dk5 created successfully.
-    pussyfoot: {104} sudo dkctl wd2 addwedge testwedge 500 100 unused
+    pussyfoot: {%} sudo dkctl wd2 addwedge testwedge 500 100 unused
     dkctl: /dev/rwd2d: addwedge: Invalid argument
-    pussyfoot: {112} sudo dkctl wd2 addwedge testwedge 534 100 unused
+    pussyfoot: {%} sudo dkctl wd2 addwedge testwedge 534 100 unused
     dkctl: /dev/rwd2d: addwedge: File exists
-    pussyfoot: {113} sudo dkctl wd2 addwedge testwedge2 534 100 unused
+    pussyfoot: {%} sudo dkctl wd2 addwedge testwedge2 534 100 unused
     dk10 created successfully.
-    pussyfoot: {114} sudo dkctl wd2 listwedges
+    pussyfoot: {%} sudo dkctl wd2 listwedges
     /dev/rwd2d: 3 wedges:
     dk5: testwedge, 500 blocks at 34, type: ffs
     dk10: testwedge2, 100 blocks at 534, type: unused
@@ -191,7 +191,7 @@
 You can see that creation of a wedge is validated, it requires a unique
 name and the wedges must not overlap.
 <pre><code>
-    pussyfoot: {140} sudo newfs NAME=testwedge
+    pussyfoot: {%} sudo newfs NAME=testwedge
     /dev/rdk5: 0.2MB (500 sectors) block size 4096, fragment size 512
             using 3 cylinder groups of 0.08MB, 21 blks, 32 inodes.
 	    super-block backups (for fsck_ffs -b #) at:
@@ -212,7 +212,7 @@
 
 A GPT can be displayed, created and edited with the GPT command:
 <pre><code>
-    pussyfoot: {9} sudo gpt show wd2
+    pussyfoot: {%} sudo gpt show wd2
             start         size  index  contents
                 0            1         PMBR
                 1            1         Pri GPT header
@@ -222,14 +222,14 @@
       11721044992          143         
       11721045135           32         Sec GPT table
       11721045167            1         Sec GPT header
-    pussyfoot: {10} sudo gpt show wd1
+    pussyfoot: {%} sudo gpt show wd1
             start         size  index  contents
                 0  11721045168         
-    pussyfoot: {10} sudo gpt show wd1
+    pussyfoot: {%} sudo gpt show wd1
             start         size  index  contents
                 0  11721045168         
-    pussyfoot: {11} sudo gpt create wd1
-    pussyfoot: {12} sudo gpt show wd1
+    pussyfoot: {%} sudo gpt create wd1
+    pussyfoot: {%} sudo gpt show wd1
             start         size  index  contents
                 0            1         PMBR
                 1            1         Pri GPT header
@@ -237,11 +237,11 @@
                34  11721045101         
       11721045135           32         Sec GPT table
       11721045167            1         Sec GPT header
-    pussyfoot: {31} sudo gpt add -a 512k -l hugedisk1 -t ccd wd1
+    pussyfoot: {%} sudo gpt add -a 512k -l hugedisk1 -t ccd wd1
     Partition 1 added, use:
             dkctl wd1 addwedge <wedgename> 1024 11721043968 <type>
     to create a wedge for it
-    pussyfoot: {57} sudo gpt show wd1
+    pussyfoot: {%} sudo gpt show wd1
             start         size  index  contents
                 0            1         PMBR
                 1            1         Pri GPT header
@@ -256,10 +256,10 @@
 Since wedges are currently only created when a device is attached, we
 need either a reboot or some magic using drvctl.
 <pre><code>
-    pussyfoot: {107} sudo drvctl -d wd1
-    pussyfoot: {108} sudo drvctl -d wd2
-    pussyfoot: {109} sudo drvctl -a ata_hl -r atabus3
-    pussyfoot: {110} sudo drvctl -a ata_hl -r atabus4
+    pussyfoot: {%} sudo drvctl -d wd1
+    pussyfoot: {%} sudo drvctl -d wd2
+    pussyfoot: {%} sudo drvctl -a ata_hl -r atabus3
+    pussyfoot: {%} sudo drvctl -a ata_hl -r atabus4
 </code><pre>
 
 The console or dmesg will reveal that both disks have been reattached
@@ -294,7 +294,7 @@
 ccd is a very old driver and has some deficiencies. For one, the ccdconfig
 tool doesn't understand wedge names.
 <pre><code>
-   pussyfoot: {10} sudo ccdconfig -c ccd0 16 none NAME=hugedisk1 NAME=hugedisk2
+   pussyfoot: {%} sudo ccdconfig -c ccd0 16 none NAME=hugedisk1 NAME=hugedisk2
    ccdconfig: NAME=hugedisk1: No such file or directory
 </code><pre>
 
@@ -312,14 +312,14 @@
 needs to be removed again. The warning comes from the attempt to read
 the disklabel from the first component.
 <pre><code>
-   pussyfoot: {42} sudo ccdconfig -u ccd0
+   pussyfoot: {%} sudo ccdconfig -u ccd0
 </code><pre>
 
 # configuring
 For now we use the wedge device directly.
 <pre><code>
-    pussyfoot: {14} sudo ccdconfig -c ccd0 16 none /dev/dk5 /dev/dk6
-    pussyfoot: {16} disklabel ccd0
+    pussyfoot: {%} sudo ccdconfig -c ccd0 16 none /dev/dk5 /dev/dk6
+    pussyfoot: {%} disklabel ccd0
     # /dev/rccd0d:
     type: ccd
     disk: ccd

(Diff truncated)
u
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 20:13:00 -0000	1.10
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 21:25:51 -0000	1.11
@@ -491,6 +491,7 @@
 </code></pre>
 
 ## using
+Wedges can be mounted by name.
 <pre><code>
     pussyfoot: {115} sudo mount NAME=stripes /mnt
     pussyfoot: {116} df -h /mnt
@@ -504,6 +505,14 @@
     pussyfoot: {121} sudo umount /mnt
 </code><pre>
 
+## checking
+And checked by name.
+<pre><code>
+pussyfoot: {49} sudo fsck NAME=stripes
+** /dev/rdk10
+** File system is clean; not checking
+</code><pre>
+
 ## and more
 And verify that this would reconfigure automatically after a reboot:
 <pre><code>

u
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 20:09:27 -0000	1.9
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 20:13:00 -0000	1.10
@@ -315,6 +315,7 @@
    pussyfoot: {42} sudo ccdconfig -u ccd0
 </code><pre>
 
+# configuring
 For now we use the wedge device directly.
 <pre><code>
     pussyfoot: {14} sudo ccdconfig -c ccd0 16 none /dev/dk5 /dev/dk6
@@ -346,6 +347,7 @@
       disklabel: super block size 0
 </code><pre>
 
+# using
 Obviously the device that spans two disks is also too large for disklabel.
 What about wedges?
 <pre><code>
@@ -371,7 +373,6 @@
 </code><pre>
 
 # Raidframe
-
 Since ccd wasn't that good, lets create a RAID0 using the raidframe driver.
 
 First, change the partition types:
@@ -416,6 +417,7 @@
     dk6: hugedisk2, 11721043968 blocks at 1024, type: raidframe
 </code><pre>
 
+## configuring
 For raidframe we need a configuration file:
 <pre><code>
     pussyfoot: {75} cat /etc/raid0.conf
@@ -468,6 +470,7 @@
     /dev/rraid0d: no wedges configured
 </code><pre>
 
+## formatting
 The raidframe driver has no problems with wedges. We can create a GPT
 on the raid device and create the wedge and format a filesystem.
 This time manually but the reattachment magic would do the same.
@@ -485,6 +488,10 @@
     super-block backups (for fsck_ffs -b #) at:
     192, 1520448, 3040704, 4560960, 6081216, 7601472, 9121728, 10641984, 12162240, 13682496, 15202752, 16723008, 18243264,
     ......................................................................................................................
+</code></pre>
+
+## using
+<pre><code>
     pussyfoot: {115} sudo mount NAME=stripes /mnt
     pussyfoot: {116} df -h /mnt
     Filesystem         Size       Used      Avail %Cap Mounted on
@@ -497,6 +504,7 @@
     pussyfoot: {121} sudo umount /mnt
 </code><pre>
 
+## and more
 And verify that this would reconfigure automatically after a reboot:
 <pre><code>
     pussyfoot: {123} sudo raidctl -u raid0

r
Index: wikisrc/users/mlelstv/using-large-disks.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/mlelstv/using-large-disks.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 19:15:34 -0000	1.8
+++ wikisrc/users/mlelstv/using-large-disks.mdwn	25 Oct 2014 20:09:27 -0000	1.9
@@ -370,4 +370,147 @@
     pussyfoot: {53} sudo ccdconfig -u ccd0
 </code><pre>
 
+# Raidframe
+
+Since ccd wasn't that good, lets create a RAID0 using the raidframe driver.
+
+First, change the partition types:
+<pre><code>
+pussyfoot: {59} sudo gpt type -i 1 -t ccd -T raid wd1
+partition 1 type changed
+pussyfoot: {60} sudo gpt type -i 1 -t ccd -T raid wd2
+partition 1 type changed
+pussyfoot: {61} sudo gpt show wd1
+        start         size  index  contents
+            0            1         PMBR
+            1            1         Pri GPT header
+            2           32         Pri GPT table
+           34          990         
+         1024  11721043968      1  GPT part - NetBSD RAIDFrame component
+  11721044992          143         
+  11721045135           32         Sec GPT table
+  11721045167            1         Sec GPT header
+pussyfoot: {62} sudo gpt show wd2
+        start         size  index  contents
+            0            1         PMBR
+            1            1         Pri GPT header
+            2           32         Pri GPT table
+           34          990         
+         1024  11721043968      1  GPT part - NetBSD RAIDFrame component
+  11721044992          143         
+  11721045135           32         Sec GPT table
+  11721045167            1         Sec GPT header
+</code><pre>
+
+And the reattachment magic:
+<pre><code>
+    pussyfoot: {107} sudo drvctl -d wd1
+    pussyfoot: {108} sudo drvctl -d wd2
+    pussyfoot: {109} sudo drvctl -a ata_hl -r atabus3
+    pussyfoot: {110} sudo drvctl -a ata_hl -r atabus4
+    pussyfoot: {69} sudo dkctl wd1 listwedges
+    /dev/rwd1d: 1 wedge:
+    dk5: hugedisk1, 11721043968 blocks at 1024, type: raidframe
+    pussyfoot: {70} sudo dkctl wd2 listwedges
+    /dev/rwd2d: 1 wedge:
+    dk6: hugedisk2, 11721043968 blocks at 1024, type: raidframe
+</code><pre>
+
+For raidframe we need a configuration file:
+<pre><code>
+    pussyfoot: {75} cat /etc/raid0.conf
+    START array
+    # numRow numCol numSpare
+    1 2 0
+    
+    START disks
+    /dev/dk5
+    /dev/dk6
+    
+    START layout
+    # sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level_0
+    16 1 1 0
+    
+    START queue
+    fifo 100
+    pussyfoot: {99} sudo raidctl -C /etc/raid0.conf raid0
+    pussyfoot: {106} sudo raidctl -I 7894737 raid0
+    pussyfoot: {106} sudo raidctl -A yes raid0
+    raid0: Autoconfigure: Yes
+    raid0: Root: No
+    pussyfoot: {100} disklabel raid0
+    # /dev/rraid0d:
+    type: RAID
+    disk: raid
+    label: fictitious
+    flags:
+    bytes/sector: 512
+    sectors/track: 32
+    tracks/cylinder: 8
+    sectors/cylinder: 256
+    cylinders: 91570655
+    total sectors: 4294967295
+    rpm: 3600
+    interleave: 1
+    trackskew: 0
+    cylinderskew: 0
+    headswitch: 0           # microseconds
+    track-to-track seek: 0  # microseconds
+    drivedata: 0 
+    
+    4 partitions:
+    #        size    offset     fstype [fsize bsize cpg/sgs]
+     a: 4294967295         0     4.2BSD      0     0     0  # (Cyl.      0 - 4294967295*)
+     d: 4294967295         0     unused      0     0        # (Cyl.      0 - 4294967295*)
+    disklabel: boot block size 0
+    disklabel: super block size 0
+    pussyfoot: {101} sudo dkctl raid0 listwedges
+    /dev/rraid0d: no wedges configured
+</code><pre>
+
+The raidframe driver has no problems with wedges. We can create a GPT
+on the raid device and create the wedge and format a filesystem.
+This time manually but the reattachment magic would do the same.
+<pre><code>
+    pussyfoot: {102} sudo gpt create raid0
+    pussyfoot: {103} sudo gpt add -a 1024 -t ffs -l stripes raid0
+    Partition 1 added, use:
+            dkctl raid0 addwedge <wedgename> 34 23442087740 <type>
+    to create a wedge for it
+    pussyfoot: {104} sudo dkctl raid0 addwedge stripes 34 23442087740 ffs
+    dk10 created successfully.
+    pussyfoot: {114} sudo newfs -O2 NAME=stripes
+    /dev/rdk10: 11446332.0MB (23442087736 sectors) block size 32768, fragment size 4096
+            using 15420 cylinder groups of 742.31MB, 23754 blks, 46848 inodes.
+    super-block backups (for fsck_ffs -b #) at:
+    192, 1520448, 3040704, 4560960, 6081216, 7601472, 9121728, 10641984, 12162240, 13682496, 15202752, 16723008, 18243264,
+    ......................................................................................................................
+    pussyfoot: {115} sudo mount NAME=stripes /mnt
+    pussyfoot: {116} df -h /mnt
+    Filesystem         Size       Used      Avail %Cap Mounted on
+    /dev/dk10           11T       4.0K        10T   0% /mnt
+    pussyfoot: {118} sudo mkdir -m 1777 /mnt/scratch
+    pussyfoot: {120} dd if=/dev/zero bs=1024k count=1000 of=/mnt/scratch/testfile
+    1000+0 records in
+    1000+0 records out
+    1048576000 bytes transferred in 4.961 secs (211363837 bytes/sec)
+    pussyfoot: {121} sudo umount /mnt
+</code><pre>
+
+And verify that this would reconfigure automatically after a reboot:
+<pre><code>
+    pussyfoot: {123} sudo raidctl -u raid0
+    pussyfoot: {124} sudo drvctl -d wd1
+    pussyfoot: {125} sudo drvctl -d wd2
+    pussyfoot: {126} sudo drvctl -a ata_hl -r atabus3
+    pussyfoot: {127} sudo drvctl -a ata_hl -r atabus4
+    pussyfoot: {127} sudo raidctl -c /etc/raid0.conf raid0
+    pussyfoot: {127} sudo mount NAME=stripes /mnt
+    pussyfoot: {191} sudo mount NAME=stripes /mnt
+    pussyfoot: {192} df -h /mnt
+    Filesystem         Size       Used      Avail %Cap Mounted on
+    /dev/dk10           11T       1.0G        10T   0% /mnt
+    pussyfoot: {193} ls -l /mnt/scratch/testfile
+    -rw-r--r--  1 mlelstv  wheel  1048576000 Oct 25 21:47 /mnt/scratch/testfile
+</code><pre>
 

Add a comment