* This is a port of evdev, the generic input event interface, from
FreeBSD. Wikipedia: "Evdev generalizes raw input events from device
drivers and makes them available through character devices in the
/dev/input/ directory."

* It is currently considered experimental since in rare cases it may cause
kernel crash when a device, e.g. usb mouse or keyboard, is detached
while a userland program reading from the corresponding input/eventX
device.

* In order to enable evdev, kernel needs to be rebuilt with 'device evdev'
and 'options EVDEV_SUPPORT'. For debugging, add 'options EVDEV_DEBUG'.

* At present, only ums, kbd and kbdmux can send events to their respective
input/eventX devices. More drivers will be added in due course. The sysctl
kern.evdev.rcpt_mask determines which drivers send events to evdev.

* write() was updating ACCESSED and MODIFIED when it should only
be updating MODIFIED.

* unlink() (aka rm) was updating CHANGE, ACCESSED, and MODIFIED
which would be visible if a file has multiple links. It should
only update the CHANGE time.

* rmdir() was doing the same thing as UNLINKED. Fixed this too,
but the bug would not be readily visible anyway since directories
cannot be hardlinked. However, fstat() on an open descriptor
would still reveal it.

* Fix the hw.usermem, hw.physmem, and hw.availpages sysctls.
Some of these were improperly 32-bit sysctls when they need
to be 64-bits, causing silly values to be returned on
machines with more than 2G of ram.

* vfs.nbuf is capped at roughly 350,000 buffer cache buffers. This
also caps buffer cache data to approximately 11G.

The reason for this is to avoid wiring too much physical memory in
the default configuration since programs might want to use the
memory fo r other purposes. Buffer cache buffers provide very fast
access when reading data from cached vnodes, but the new KVABIO ABI
will soon allow us to acquire and dispose of such buffers more
efficiently, increasing the efficiency of accessing data cached via
the block device and making long-term caching via vnode-backed
buffers somewhat less important.

* kern.maxvnodes is capped at approximately 3 million vnodes. This
can be set higher at run-time via a sysctl, if desired.

NOTE: Our go-to filesystems are designed to or can be set to cache
file data via the block device instead of the vnode, which is
preferable on systems with lots of memory. vnode caching is
still important, but a bit less so now than in prior years.

* debug.max_softdeps is capped at 1000000, because even a million
is an obscenely high value for softdep structures.

* Increase the DMAP from 64 PDP pages to 128 PDP pages, allowing
support for up to 64TB of physical memory.

* Changes the meaning of KPML4I from being 'the index of the only
PDP page in the PML4e' to 'the index of the first PDP page in
the PML4e'. There are NKPML4E PDP pages starting at index KPML4I.

* NKPDPE can now exceed 512. This is calculated to be the maximmum
number of PD pages needed for KVM, which is now (NKPML4E*NPDPEPG-1).

We now pre-allocate and populate only enough PD pages to accomodate
the page tables we are pre-installing. Those, in turn, are calculated
to be sufficient for bootstrapping mainly vm_page_array and a large
initial set of pv_entry structures.

* Do not call cache_setunresolved() on tnch before calling
cache_rename(). Doing so prevents cache_rename() from properly
setting VREF_FINALIZE on the vnode. Since the deleted inode is
no longer in the chain hierarchy the related chains can remain
dirty indefinitely (until the vnode is reused or the filesystem
is unmounted).

* Only implement the parts relevant for display powersaving when a KMS
graphics driver is loaded. Adjust the existing V_DISPLAY_* constant
definitions to match the corresponding definitions in FreeBSD.

First let's get it straight. It is censorship and let's not sugar coat it.

The FO has fallen, N is falling and naturally we are next.
I'm only doing this to prevent certain discussions taking place on the mailing
lists or irc over the holidays and to explictly show irony of all this ${thing}.
It is SAD to see that various projects went from technical to being PC infested.
So much for being the flagmans of OSS developments & examples to other projects.
(slow ironic clapping insert here)
Such slabnij individuals with "hurt feelings" always are causing developers to
get distracted from their hacking on source or making hardware work properly.
Also, these actions opens up the door wider for "other" topics into discussions.

I'm not going to mention the name of certain evil* person so that this would not
get "flagged". Absurdity is already way beyond any reasonable levels. Clearly
there are some perpetually offended snoflakes, who have nothing better to do
other than look for ways to get offended or to trigger other people in real life
and over the internet. Why not just choose one? If someone wants to let some
accumulated steam off, there are places over the internet where one can have a
constructive conversation about certain topics. If you can not handle the raw,
unredacted, straight opinions, you must be new there, please kindly go back to
reddit safe spaces. Just do *not* bring those talks over into the projects!
It is very likely that not everybody feels the same or even cares.
This is literally "Look what you made me do!", so here we go.

I'm going to consider cookies removal *only* and *only* if some things are
declared illegal by the country/state law with a reference to look it up where
it clearly states what is illegal to quote (including if that applies to the
translated text variants). No "probably" stuff. Either it's illegal or it's not.
If you are not sure, you should consult with your country/state lawyers first.

By going trough MSM and lists it is clear that some find offensive *not* the
quotes by itself but the mere mention of certain letter combinations. Since I do
not share identical ideology as most westerners (I was born in 19 88, USSR, and
with collapse of Soviet union and 19 91 events my fundation is a different myth)
I'm expanding "grep ${pattern} datfiles/fortune" to include Stalin for lulz too.
Many Lithuanians and Ukrainians find "admirating" that historic figure offensive
too, mainly because of "free" trips to Siberia, brothers and sisters separated
from parents, etc. Still it is not for me to judge the history nor rewrite it.

For now I'm keeping all Communism/Capitalism cookies just as a satire. But I'm
moving the qoute by Adolfo Guzman too, cause "sorry it matched the patternTM".
Doing this solves the following issues:
* does not single out any specific individual (just a pattern right?);
* clearly expresses irony and shows how some are so biased and have no
understanding that their actions have consequences.

If for some reason you still find something offensive, check out "man 6 fortune"
for "-o" flag. Of course, if (for some reason) you do not want the potentially
"offensive" aphorisms on your disk, you can opt out:
* echo 'INSTALL_OFFENSIVE_FORTUNES=NO\!\!\!\!' >> /etc/make.conf
* standard buildworld/installworld
* make upgrade
and problem solved.

If still find things like fortune(6), hangman(6), pig(6) or maybe even tetris(6)
"offensive", set NO_GAMES=YES and get rid of all games distrib (I don't judge).
Since we are source based distribution (and no, BSD does *not* stand for Binary
Software Distribution) we provide installation images just for convenience. We
do not support binary base upgrades, only the standard source tree build ones.

To be clear, I had some of these fortune cookies added over a year ago in:6c5aea60b8d9d163c6caa536036e82e7472b84bc and nobody so far complained about it.
It is still very strange that previously those were OK. So what has changed now?

What if I'm offended by software bugs? Should I remove that sofware or try to
fix it? What if someone is offended by the license say GPL, CDDL or even Apache?
So far censorship applies only to games/fortune/.

All of this is just something to think about & no further talks will take place.
Respect others and respect yourself. Also, don't get offended to get offended.
I can only hope that infinity will forgive me, but this needs to be done.

Revive the old x86 32bit only fdc(4) driver, it only needs just a few changes.
The fdc was never ported to work on x86_64 DragonFly, so rather than remove it
together with its manpage, fix few things and hook it to LINT64 config so that
we would keep track the state of it and not keep it in a dusty corner of sys/.

On modern x86_64 systems fdc($) has little value and it is getting harder and
harder to find floppy drives that work or even the motherboards that still have
the FDD headers to hook the 34pin ribbon cable, but I feel nostalgic about the
scratching noises the floppy drive makes while performing the operations.
So went through all storage closets and find one that works, blew out all the
accumulated dusts, cleaned the magnetic heads with a folder paper tissue good.
The hardest part was to find a floppy disk. Only could find just a single one
stashed away deep on the floor of a very old safe under heeps of old documents.

For fdc(4) to actually work, some adjustmens to isa_dma.c were needed because
of how ISA bus probing is done in platform/pc64/x86_64/autoconf.c. To work
around the exhaustion of low DMA memory before it gets to isa_probe_children()
now try to preallocate contiguous buffer of 512KB and free it just before the
probe of ISA bus. This should help any legacy ISA drivers(including ppc(4))
or even some of more picky drivers that are not built in into the kernel.

For case where isa_dmainit() would still fail to allocate the buffer fitting
the requirements, have added the safety checks and explicit fallback to non
DMA mode by setting the FDC_NODMA flag to avoid panics on "bad bounce buffer".
Floppy drive would not work properly, but it is this versus a panic. There are
other issues too. For some reason some files tend to be read with stripes of
zeros, but write operations seems to work. Same floppy is readable on linux.

FreeBSD did that 3 years ago (r274331). Quoting from their commit msg:

-----8<-----
It looks like industry have chosen different (and more traditional)
stateless/stateful NAT64 as translation mechanism. Last non-trivial
commits to both faith(4) and faithd(8) happened more than 12 years
ago, so I assume it is time to drop RFC3142 in FreeBSD.
----->8-----

* Refactor uservtophys() to use vm_fault_page(). The pmap
lookup isn't going to work coupled with the fuword style
test because the vkernel's copyin/copyout/fuword/etc code
doesn't fault the underlying page into the pmap.

* Allow a vnode being destroyed to have a dirty VM object. TMPFS
doesn't bother to cleanup VM objects when destroying file nodes
(e.g. when a file that is no longer referenced is removed), and
can leave dirty pages present in the underlying object.