FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.2 2018-04-06T17:35:35Z 2018-04-06T17:35:35Z Brooks Davis brooks@FreeBSD.org 2018-04-06T17:35:35Z urn:sha1:6469bdcdb6a5968dc7edfcfb495d427b4bfdb3dd opt_compat.h is mentioned in nearly 180 files. In-progress network driver compabibility improvements may add over 100 more so this is closer to "just about everywhere" than "only some files" per the guidance in sys/conf/options. Keep COMPAT_LINUX32 in opt_compat.h as it is confined to a subset of sys/compat/linux/*.c. A fake _COMPAT_LINUX option ensure opt_compat.h is created on all architectures. Move COMPAT_LINUXKPI to opt_dontuse.h as it is only used to control the set of compiled files. Reviewed by: kib, cem, jhb, jtl Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D14941 2018-03-14T21:11:41Z Brooks Davis brooks@FreeBSD.org 2018-03-14T21:11:41Z urn:sha1:f287c3e4d332919117611581381d81fe1539909f This includes FSACTL_LNX_GET_NEXT_ADAPTER_FIB. Reviewed by: cem Obtained from: CheriBSD MFC after: 1 week Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D14672 2017-03-04T10:10:17Z Enji Cooper ngie@FreeBSD.org 2017-03-04T10:10:17Z urn:sha1:193d9e768ba63fcfb187cfd17f461f7d41345048 This simplifies make output/logic Tested with: `cd sys/modules; make ALL_MODULES=` on amd64 MFC after: 1 month Sponsored by: Dell EMC Isilon 2010-08-23T06:13:29Z Warner Losh imp@FreeBSD.org 2010-08-23T06:13:29Z urn:sha1:c09808d0d611d103bece3d41886b87de160900c0 Use MACHINE_CPUARCH in preference to MACHINE_ARCH. The former is the source code location of the machine, the latter the binary output. In general, we want to use MACHINE_CPUARCH instead of MACHINE_ARCH unless we're tesitng for a specific target. The isn't even moot for i386/amd64 where there's momemntum towards a MACHINE_CPUARCH == x86, although a specific cleanup for that likely would be needed... 2004-08-30T03:35:17Z Scott Long scottl@FreeBSD.org 2004-08-30T03:35:17Z urn:sha1:7aabd9220da51e96b27324562306989f6fd882ed 2003-02-26T06:56:46Z Scott Long scottl@FreeBSD.org 2003-02-26T06:56:46Z urn:sha1:3f9be55c27e315df5bbdbeb929b2aac2d8384d5f 2003-02-26T03:15:42Z Scott Long scottl@FreeBSD.org 2003-02-26T03:15:42Z urn:sha1:7874f606d5cefa443c96bc218d76d696db6f1a69 turns runs its tasks free of Giant too. It is intended that as drivers become locked down, they will move out of the old, Giant-bound taskqueue and into this new one. The old taskqueue has been renamed to taskqueue_swi_giant, and the new one keeps the name taskqueue_swi. 2002-11-06T13:41:40Z Yoshihiro Takahashi nyan@FreeBSD.org 2002-11-06T13:41:40Z urn:sha1:c7a1bf8bf3d6108176c13e8f9cb1a8f0ab7dfb15 2002-09-25T05:00:25Z Scott Long scottl@FreeBSD.org 2002-09-25T05:00:25Z urn:sha1:7419815d60b31c9daeb2f10ed7b088c20917dc02 aac driver dependent on the linux emulation module. This was especially bad for the release engineers who tried to move the aac driver from the kernel onto the drivers floppy. The linux compat bits for this driver are now in their own driver, aac_linux. It can be loaded as a module or compiled into the kernel. For the latter case, the AAC_COMPAT_LINUX option is needed, along with the COMPAT_LINUX option. I've tested this in every configuration I can think of. This is an MFC candidate for 4.7. Idea from: rwatson MFC after: 3 days 2002-04-27T01:31:17Z Scott Long scottl@FreeBSD.org 2002-04-27T01:31:17Z urn:sha1:fe3cb0e1ec289f1806e8729e5a95b7285d64617e ever connect a SCSI Cdrom/Tape/Jukebox/Scanner/Printer/kitty-litter-scooper to your high-end RAID controller. The interface to the arrays is still via the block interface; this merely provides a way to circumvent the RAID functionality and access the SCSI buses directly. Note that for somewhat obvious reasons, hard drives are not exposed to the da driver through this interface, though you can still talk to them via the pass driver. Be the first on your block to low-level format unsuspecting drives that are part of an array! To enable this, add the 'aacp' device to your kernel config. MFC after: 3 days