Searched hist:1.1204 (Results 1 - 12 of 12) sorted by relevance
| /src/sys/dev/pci/ | ||
| H A D | pcidevs.h | 1.1204 Wed Dec 31 21:21:41 GMT 2014 veego Regen |
| H A D | pcidevs_data.h | 1.1204 Wed Jan 14 15:28:18 GMT 2015 msaitoh regen. |
| H A D | pcidevs | 1.1204 Wed Oct 29 10:21:53 GMT 2014 nonaka Add Realtek RTL8402 PCI-E Card Reader. |
| /src/doc/ | ||
| H A D | 3RDPARTY | 1.1204 Wed Feb 11 20:12:22 GMT 2015 riastradh Document drm crap in 3RDPARTY. |
| H A D | CHANGES | 1.1204 Sun Mar 29 10:56:43 GMT 2009 ad uvm_kmguard chgs |
| /src/sys/arch/i386/conf/ | ||
| H A D | GENERIC | 1.1204 Fri Mar 01 00:23:10 GMT 2019 nonaka commented out hvkvp entry. |
| /src/distrib/sets/lists/base/ | ||
| H A D | mi | 1.1204 Tue May 07 05:02:41 GMT 2019 thorpej Add installboot(8) support for evbarm (and, in the future, other evb*) boards that use u-boot. A known board database lists boards and their respective u-boot packages. u-boot packages are discovered at run-time (in /usr/pkg/share/u-boot, by default). These packages contain board database overlays that describe u-boot installation procedure that's specific for that board. Support this as a native tool and as a host tool. The native tool will attempt to determine the running board type using OpenFirmware calls. Host tool and native tool alike may also specify a board type directly using the "-o board=xxx option" or have installboot(8) determine the board type from a device tree blob using "-o dtb=/path/to/board.dtb". A "-o media=xxx" option is provided for boards that have different u-boot binaries and/or installation procedures for different media types (e.g. SDMMC, eMMC, or USB). This is trivial to extend to other evb* platforms that use u-boot, even if they don't use FDT for autoconfiguration. |
| /src/distrib/sets/lists/man/ | ||
| H A D | mi | 1.1204 Thu Apr 22 06:48:28 GMT 2010 jruoho Rewrite types(5) as per perry@'s suggestion from few years back ("XXX this document is rather musty. It needs a general update."). Also move it to the right section from section 5. Ok wiz@. To minimize maintenance costs, the content is mostly jargon around The Standard. Only few NetBSD-specific types are mentioned as an example. |
| /src/distrib/sets/lists/tests/ | ||
| H A D | mi | 1.1204 Thu May 12 00:09:44 GMT 2022 rillig tests/lint: adjust tests to reflect missing support of __alignof__ The change in lex.c 1.129 attempted to add support for __alignof, in addition to the existing support for __alignof__. It failed by removing support for __alignof__, while allowing the plain 'alignof' instead. |
| /src/share/mk/ | ||
| H A D | bsd.own.mk | 1.1204 Sun Aug 16 06:43:05 GMT 2020 mrg switch netbsd/m68k to GCC 8. special thanks to rin@ for fixing many things and figuring out what was the major issue (STACK_BOUNDARY.) |
| /src/sys/conf/ | ||
| H A D | files | 1.1204 Mon Aug 20 15:04:52 GMT 2018 maxv Add support for kASan on amd64. Written by me, with some parts inspired from Siddharth Muralee's initial work. This feature can detect several kinds of memory bugs, and it's an excellent feature. It can be enabled by uncommenting these three lines in GENERIC: #makeoptions KASAN=1 # Kernel Address Sanitizer #options KASAN #no options SVS The kernel is compiled without SVS, without DMAP and without PCPU area. A shadow area is created at boot time, and it can cover the upper 128TB of the address space. This area is populated gradually as we allocate memory. With this design the memory consumption is kept at its lowest level. The compiler calls the __asan_* functions each time a memory access is done. We verify whether this access is legal by looking at the shadow area. We declare our own special memcpy/memset/etc functions, because the compiler's builtins don't add the __asan_* instrumentation. Initially all the mappings are marked as valid. During dynamic allocations, we add a redzone, which we mark as invalid. Any access on it will trigger a kASan error message. Additionally, the compiler adds a redzone on global variables, and we mark these redzones as invalid too. The illegal-access detection works with a 1-byte granularity. For now, we cover three areas: - global variables - kmem_alloc-ated areas - malloc-ated areas More will come, but that's a good start. |
| /src/distrib/sets/lists/comp/ | ||
| H A D | mi | 1.1204 Mon Nov 10 04:06:16 GMT 2008 dogcow Move all the xorg/x11 linty stuff from comp/mi -> xcomp/mi |
Completed in 1653 milliseconds