switch over to unified MAKEDEV

Really remove ed0 and ed1

g/c ed0/ed1 nodes, the hardware is not present on amd64

reassing majors for crypto and pf to use the newly defined MI major range

Add a /dev/constty == /dev/console but with minor 1.
Use for tty sessions on 'console' so that output doesn't pinched by anyone
using TIOCCONS to get kernel and system messages.

add isdn telephony dialout devices

Change the way pseudo tty devices are generated in order to avoid
any pipes and running other commands (eg dd).
Measurable speeds up creating pseudo ttys.
(there has to be a better way than editing 51 files! - tedious at only
6 key presses per file)

create /dev/crypto

reserve cdev major # for PF. ok'ed by technical-exec

Remove device nodes for obsolete olms and omms drivers.
Except for i386, the driver never existed for that port anyway...

fix ugen issue from latest shell changes that treat numeric constants
differently depending on their prefix.

Add ksyms to "std" devices.

x86_64 -> amd64

MAKEDEV: New `virtio' target for all virtio-related devices.

We can use this to add more as they come up so we don't have to keep
tweaking every etc.${MACHINE}/MAKEDEV.conf every time. Currently
this makes nodes for viocon(4) and vio9p(4).

(Not all GENERIC kernels enable vio9p(4) but I suspect the ones that
don't really should; for those that are disabled because PAGE_SIZE !=
4096, I expect it's just a matter of some additional indexing to make
vio9p(4) work with other page sizes.)

PR kern/59211: vio9p(4): missing from various GENERICs and MAKEDEVs

branches: 1.36.2;
MAKEDEV: Tidy some entries on x86 and Arm.

While here, reduce some diffs arising from ordering and formatting
between these architectures.

Only difference between evbarm and aarch64 now is /dev/vchiq. Not
sure offhand if it makes sense on aarch64 or only 32-bit Arm.

PR port-amd64/58093: /dev/efi missing on x86
PR port-arm/58100: /dev/ttyVI* missing on aarch64
PR port-arm/58101: /dev/nvme* missing on aarch64
PR port-arm/58102: /dev/raid* missing on aarch64

branches: 1.35.2;

Don't forget pci17

viocon(4): New virtio tty driver imported from OpenBSD.

viocon* at virtio?

/dev/ttyVI??

Tested under qemu with:

qemu-system-aarch64 ... \
-device virtio-serial \
-chardev socket,path=/tmp/ttyVI00,server=on,wait=off,id=ttyVI00 \
-device virtconsole,chardev=ttyVI00,name=org.NetBSD.dev.ttyVI00 \
...

I updated MAKEDEV.conf to create /dev/ttyVI?? on all ports where it
looks likely to work based on:
(a) having pci or a non-pci virtio attachment,
(b) `qemu-system-$ARCH -M ?' mentioned something resembling the port,
and
(c) `qemu-system-$ARCH -device virtio-serial' launched without
complaining about the virtio-serial device.

(Criterion (c) excluded sparc and sparc64.)

smbios: Add character device for accessing SMBIOS tables

The /dev/smbios character device gives an aperture into physical memory
that allows read-only access to the SMBIOS header and tables.

acpi: add character device for accessing ACPI tables

The /dev/acpi character device gives an aperture into physical memory
that allows only read access to known ACPI tables: RSDP, XSDT/RSDT, and
the root tables. Adapt acpidump(8) to use this interface by default,
falling back to the old /dev/mem method if it is not available or if
ACPIDUMP_USE_DEVMEM=1 is set in the environment. The user visible benefit
of this change is that "options INSECURE" is no longer required to
dump ACPI tables.

Create 8 /dev/ldX by default, as with other disk drivers and ports

add support for wwanc(4) device nodes (xmm[0-9])

remove nsmb from MD list of devices to create for 'all'

branches: 1.28.2;
Create up to pci19.

We probably don't need more than one pci file, but the code needs to be
changed for it, which might introduce problems, and we're just before a
branch.

Not needed for evbarm because it uses devpubd by default.

Stopgap fix for PR xsrc/54388.

Remove the satlink driver. It was disabled everywhere, had no man page and
no use either. Spotted by thorpej in PR/21345, ok christos.

Add /dev/nvmm.

Add tprof

Remove ISDN from the kernel. It has remained unmaintained for a long time,
is of poor quality, and is now an obstacle to MP-ification. It was removed
ten years ago from FreeBSD for the same reason.

This retires a big user of the mbuf API, and will ease maintenance of the
kernel.

branches: 1.23.12; 1.23.14;
fix incorrect nvme controller number.

Add NVMe command passthrough support.

don't make ipty. postinstall removes them.

add more sd and pci devices.
remove duplicate ch0.

Add a pass-through ioctl for mfi(4), allowing userland to send raw commands
to the controller. This is compatible with the linux and FreeBSD
implementations.
Add the needed conversion for mfi ioctls in COMPAT_LINUX
Allocate a character major number, and create /dev/mfi0 by default
on amd64 and i386.
This allows (along with a hand-created /emul/linux/proc/devices file)
to run the MegaCLI linux binary provided by LSI.

branches: 1.18.2;
give wedges to everyone

branches: 1.17.4; 1.17.6;
Import the Flash and NAND subsytem code contributed by the University
of Szeged, Hungary.

The commit includes:
- Flash layer, which gives a common API to access flash devices
- NAND controller subsystem for the flash layer
- An example OMAP driver which is used on BeagleBoard or alike ARM boards

branches: 1.16.4;
Now that the installation floppies are including tmpfs as well, stop
distinguishing MAKEDEV init and MAKEDEV all for x86.

Create 8 dk instances by default.

Can't type. xkbd -> xbd.

Create 4 Xen disks by default and all three Xen devices to make it
usable out-of-the-box.

branches: 1.12.2;
Move "makedev cfs" for the vcoda device from MI MAKEDEV.tmpl to
MD MAKEDEV.conf. Not all ports have vcoda in their majors.foo files
and we shouldn't (re)assign major numbers on all ports before 5.0.

Should close PR port-sgimips/38962.

branches: 1.11.4; 1.11.8; 1.11.12;
Add Xen devices

branches: 1.10.4;
Create /dev/bio

Increase the number of raid(4) device node sets to four and the number
of wd(4) device node sets to eight. This fixes another problem
reported in PR port-amd64/35532

Fix MAKEDEV on shark: Move ses(4) devices from MI code (MAKEDEV.tmpl) to
those platforms that actually have the driver.

See also:
http://mail-index.netbsd.org/tech-userlevel/2007/01/08/0001.html

Fixes PR 26511 properly.

OK'd by wrstuden@

branches: 1.7.4;
Add a /dev/amr* control file for amr(4) devices, which allows sending raw
commands to the controller.
Add a amrctl(8) control tool, which for now only allows to get status
from the adapter (status of adapter, logical volumes and and individual
drives).
From FreeBSD, with some adjustements by Andrew Doran and me.

branches: 1.6.2;
Only make bpf, not bpfN

no dmoverio either

no apm

determine the platform number of disk partitions by looking
at MAXPARTITIONS/OLDMAXPARTITIONS in kernel sources, so that it wouldn't
need to be specified separately in MAKEDEV.conf

change platform MAKEDEV.conf to contain only MD targets and nothing else;
simplify the parsing in MAKEDEV.awk accordingly

g/c ed0/ed1 nodes, the hardware is not present on amd64

MD part of unified MAKEDEV
this contains information about disk partitions used by platform,
and MD MAKEDEV targets, such as 'init', MD part of 'all',
as well as any other MD-specific targets not covered by MAKEDEV.tmpl

Distribute the MICROVM kernel on amd64 and i386.

See sys/arch/{amd64,i386}/conf/MICROVM for usage instructions.

branches: 1.17.4;
x86: Release the ramdisks too.

This way we will get cgdroot.fs (and zfsroot.fs too) in the release.

PR misc/57534

branches: 1.16.2; 1.16.10;
Distribute GENERIC_KASLR on amd64.

branches: 1.15.8; 1.15.14; 1.15.16;
Nuke the five(!) install floppies. Welcome to 2015. Approved by
dsl@, Master of Port.

branches: 1.14.12;
Disable GENERIC_USERMODE kernel auto-build to avoid problems with the current
autobuild-system.

Move i386 and amd64 usermode configurations to their respective directories
and make the usermode kernels buildalbe under build.sh.

The resulting kernels are build and packaged correctly as are the associated
modules.

branches: 1.12.6;
Build miniroot.kmod installation module for amd64. Hook GENERIC
with it.

See http://mail-index.netbsd.org/port-i386/2011/01/14/msg002247.html

Convert all the etc/etc.*/Makefile.inc to use RELEASEDIR/RELEASEMACHINEDIR
just like etc/Makefile does.

branches: 1.10.2; 1.10.4; 1.10.6;
Remove GENERIC.MP config and enable SMP by default on amd64.

Build amd64 xen kernels, and include them in the distrib.

branches: 1.8.4; 1.8.6;
Add a comment reminding to update the release notes if the list of
kernels change.

For the benefit of modern hardware, enable ACPI by default in INSTALL and
GENERIC kernels. If ACPI is an issue on your hardware, 'boot -c' and
'disable acpi' should be a workaround. ACPI-enabled kernels works fine
on pre-acpi hardware.
for amd64:
- add ACPI to INSTALL and GENERIC, remove the *_ACPI config files.
- get rid of the bootfloppy-big.fs boot image, and got to a 3-floppy boot
image
for i386:
- introduce INSTALL_LARGE which has ACPI and some devices with big firmware
- move some devices from INSTALL to INSTALL_LARGE
- Boot floppies still use INSTALL, and bootfloppy-big.fs is still there
(for thoses who want to build el-torito floppy emulation boot CD) and use
INSTALL.
For both, drop the 'iso-image' code in etc/ to make the iso bootable, we'll
use something else to build bootable CDs.

Install pxeboot_ia32.bin as part of a "make release" on i386 and amd64.

branches: 1.5.4;
Add & enable boot-CDs (with ramdisk kernels only, no install sets),
built as part of a regular release. For more information, see
http://mail-index.netbsd.org/tech-install/2006/05/11/0001.html

OK: core@

Add GENERIC_ACPI and INSTALL_ACPI kernels to the build.

Fix iso-image support.

x86_64 -> amd64

x86_64 -> amd64

Undo loading pciverbose module by default.
See item 14 in src/doc/TODO.modules.

Make use of the pcidevs database by default.

Express more confidence in our ability to boot on hardware with ACPI
enabled and don't warn our users that it might not and already suggest
workarounds.

The ability to disable ACPI and SMP is still there, by dropping to
the boot prompt.

branches: 1.5.4;
Instead of explicitly specifying a kernel name, ommit to allow the bootloader to iterate
through the list of kernel names it is configured to try. This way there is
fallback if /netbsd is not present. netbsd is the first name to be tried anyway.
Issue brought up on tech-kern@ by Patrick Welche <prlw1 AT cam ac uk> where a system
without /netbsd hung on boot.
Suggestion by rudolf <netbsd AT eq cz>
https://mail-index.netbsd.org/tech-kern/2018/02/16/msg023122.html

bootmenu doesn't parse "prompt" as part of a command list, it must
stand alone.

Use random seed file (saved entropy) from default location by default
in i386 and amd64 boot.cfg.

branches: 1.2.8;
add clear=1

branches: 1.1.4; 1.1.6;
Give i386 and amd64 a default boot.cfg.

Arch-specific rc.conf files are not really autonomous rc.conf
files, they are appended to the end of etc/defaults/rc.conf.

So rename them to rc.conf.append for clarity, as suggested by mrg@. Adapt
Makefile accordingly.

Modify etc/defaults/Makefile so that architectures can specify an additional
rc.conf file. This one should reside under etc/etc.${MACHINE}/, and will
get automatically appended to etc/defaults/rc.conf at build time if present.

This is used by i386 and amd64 to append a small MD rc.conf(5) configuration
at the end of the defaults/rc.conf file, so that powerd(8) can be started
by default when we are running in a Xen environment. This is needed to support
save/restore functions for domains.

From all the alternatives proposed to fix that issue (from /etc/rc.conf
parsing in postinstall to etc/defaults/rc.conf arch-hooks) I believe
this one will appease everyone because it:
- does not touch etc/defaults/rc.conf template file,
- patches it at build time for MD hooks only when required,
- does not need to parse/modify a user-specified file like /etc/rc.conf (which
is a complex, error-prone operation),
- only enables powerd(8) by default when conditions are met (Xen environment)
while still allowing root to shoot himself in the foot if he wants to
override this manually in /etc/rc.conf.

See also http://mail-index.netbsd.org/tech-userlevel/2011/07/25/msg005246.html

default powerd=YES if acpi is present

branches: 1.1.2;
Arch-specific rc.conf files are not really autonomous rc.conf
files, they are appended to the end of etc/defaults/rc.conf.

So rename them to rc.conf.append for clarity, as suggested by mrg@. Adapt
Makefile accordingly.

x86_64 -> amd64

Switch default console tty from /dev/console to /dev/constty

With this switch processes (such as xconsole) can open /dev/console
without breaking login on the text or serial console. This can be
trivially triggered by enabling xdm in rc.conf and hitting
Ctrl+Alt+F1 or equivalent once booted.

The changes:
- Add entry for /dev/console or /dev/constty if missing
- If a port's had /dev/console 'on' switch it off and enable /dev/constty
- If a port did not have /dev/console 'on', leave /dev/constty off

Some ports had /dev/console off and /dev/ttyE0 enabled, presumably to
avoid just this issue. It may make sense to adjust these also (but not
in this pass)

As discussed on current-users

branches: 1.6.34; 1.6.36;
Per discussion on tech-userlevel, finally fix PR 10127:
move all ttyE* entries that use "vt100" emulation to wsvt25 term type.
The terminfo vt220 entry lacked (correctly) a delete key entry, which
was a regression against the netbsd-5 termcap entry. On the other hand,
only a very small number of foreign systems lacks support for wsvt25
nowadays.

branches: 1.5.18; 1.5.20;
Add a constty entry, marked 'off', with otherwise the same settings
as the console. Now when coming up in single user mode the tset in
/.profile can set the terminal type correctly.
Note: I believe constty should be 'on' and console 'off', but thats a
separate discussion

branches: 1.4.26;
remove ad-hok list of pty's from port tty files, and auto-generate it so
that it is consistent, and in the proper order.

Revert 'console' back to /dev/console (from /dev/constty)

Change 'console' login to use /dev/constty so that its output isn't
stolen by code that requests system messages using TIOCCONS.

x86_64 -> amd64