sed: use getline() instead of fgetln().

In BSD, fgetln() available in libc but in Illumos the Solaris port had to
include it internally. It also seems to have caused problems [1].

Aid portability by using getline() instead.

Reference:
https://www.illumos.org/issues/3820 [1]

Submitted by:	Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.com>
Reviewed by:	dds
MFC after:	2 weeks
Document ifconfig_wlanX="HOSTAP"
Add a stub AR93xx RF module just to keep the linker happy.

When building AR933x test images, I'd like to only build only the ar9300
HAL.  To do this, it needs to supply an RF linker entry or it won't compile.

Tested:

* AR933x test builds
In preparation to support AR933x SoC builds, allow the AH_SUPPORT_AR93(xx)
options to set the AR9300 HAL defines.

This enables the Wasp, Hornet (and later Scorpion) SoC code.
Add a HAL local routine to map the 2GHz channel frequency to an IEEE
channel.

There's some HAL code in the AR9300 HAL that requires a back-mapping
and using the net80211 code isn't appropriate here.
Re-enable the channel set code for the AR933x.

This required a HAL change to map the 2GHz frequency back to an IEEE
channel number in order to fetch some value(s) to program in.
If EEPROM data is provided by the AHB layer, copy it in.

This is required for the flash layer code to correctly work.

Tested:

* AR9330 SoC (carambola 2)
Extend the AHB code to work on chips besides the AR9130.

The AHB code:

* hard coded the AR9130 device id;
* assumes a 4k flash calibration space.

This code now extends this:

* hint.ath.X.eepromsize now overrides the eeprom range, instead of 4k
* hint.ath.X.device_id and hint.ath.X.vendor_id can now be overridden.

Tested:

* AR9330 board (Carambola 2)
Add in two new configuration options for the current generation SoCs.
Add the wireless support to the AR933x base kernel, as the support
actually works now.
Add in the vendor / device id so the ath_ahb glue works.
Add the EEPROM start offset and size in so ath_ahb will use the
supplied EEPROM data.

This needs to die in a fire and replaced with the firmware API
to store the calibration data early ..
Fix some UTF-8 chars slipped into r252204 via copy/paste.
Minor sorting.

MFC after:	3 days
In the Xen block front driver, take advantage of backends that
support cache flush and write barrier commands.

sys/dev/xen/blkfront/block.h:
	Add per-command flag that specifies that the I/O queue must
	be frozen after this command is dispatched.  This is used
	to implement "single-stepping".

	Remove the unused per-command flag that indicates a polled
	command.

	Add block device instance flags to record backend features.

	Add a block device instance flag to indicate the I/O queue
	is frozen until all outstanding I/O completes.

	Enhance the queue API to allow the number of elements in a
	queue to be interrogated.

	Prefer "inline" to "__inline".

sys/dev/xen/blkfront/blkfront.c:
	Formalize queue freeze semantics by adding methods for both
	global and command-associated queue freezing.

	Provide mechanism to freeze the I/O queue until all outstanding
	I/O completes.  Use this to implement barrier semantics
	(BIO_ORDERED) when the backend does not support
	BLKIF_OP_WRITE_BARRIER commands.

	Implement BIO_FLUSH as either a BLKIF_OP_FLUSH_DISKCACHE
	command or a 0 byte write barrier.  Currently, all publicly
	available backends perform a diskcache flush when processing
	barrier commands, and this frontend behavior matches what
	is done in Linux.

	Simplify code by using new queue length API.

	Report backend features during device attach and via sysctl.

Submitted by:	Roger Pau Monné
Submitted by:	gibbs (Merge with new driver queue API, sysctl support)
For ATA_PASSTHROUGH commands, pretend isci(4) supports multiword DMA
by treating it as UDMA.

This fixes a problem introduced in r249933/r249939, where CAM sends
ATA_DSM_TRIM to SATA devices using ATA_PASSTHROUGH_16.  scsi_ata_trim()
sets protocol as DMA (not UDMA) which is for multi-word DMA, even
though no such mode is selected for the device.  isci(4) would fail
these commands which is the correct behavior but not consistent with
other HBAs, namely LSI's.

smh@ did some further testing on an LSI controller, which rejected
ATA_PASSTHROUGH_16 commands with mode=UDMA_OUT, even though only
a UDMA mode was selected on the device.  So this precludes adding
any kind of mode detection in CAM to determine which mode to use on
a per-device basis.

Sponsored by:	Intel
Discussed with:	scottl, smh
Reported by:	scottl
Tested by:	scottl
MFC after:	3 days
Add an open_dev() helper function to be used in the various places
where nvmecontrol needs to open a handle to a controller or namespace
device node.

Sponsored by:	Intel
MFC after:	3 days
Add separate *_usage() functions for each nvmecontrol command.

Sponsored by:	Intel
MFC after:	3 days
Break out code related to the devlist command into a separate source file.

Sponsored by:	Intel
MFC after:	3 days
Break out code related to the identify command into a separate source file.

Sponsored by:	Intel
MFC after:	3 days