Searched hist:1.1357 (Results 1 - 10 of 10) sorted by relevance
| /src/sys/dev/pci/ | ||
| H A D | pcidevs.h | 1.1357 Thu Apr 11 05:06:53 GMT 2019 mrg regen. |
| H A D | pcidevs_data.h | 1.1357 Fri Apr 12 04:50:21 GMT 2019 msaitoh Regen. |
| H A D | pcidevs | 1.1357 Wed Dec 26 08:25:20 GMT 2018 msaitoh Add yet another Intel Core QuickPath Generic Non-Core Register. |
| /src/doc/ | ||
| H A D | 3RDPARTY | 1.1357 Sat Sep 03 23:31:53 GMT 2016 wiz Update llvm info. |
| H A D | CHANGES | 1.1357 Tue Feb 09 01:48:29 GMT 2010 msaitoh mention about mfi(4)'s GEN2 support. 1.1357 Tue Feb 09 01:48:29 GMT 2010 msaitoh mention about mfi(4)'s GEN2 support. |
| /src/distrib/sets/lists/base/ | ||
| H A D | mi | 1.1357 Wed Feb 05 20:26:04 GMT 2025 christos Add ipf.conf example for blocklist |
| /src/distrib/sets/lists/man/ | ||
| H A D | mi | 1.1357 Thu Nov 24 21:42:08 GMT 2011 ahoka add mount_chfs.8 |
| /src/distrib/sets/lists/tests/ | ||
| H A D | mi | 1.1357 Sat Jan 18 22:31:22 GMT 2025 rillig tests/gcov: demonstrate wrong coverage report after vfork/exec Discovered in usr.bin/make, function Cmd_Exec. The coverage test I ran on 2024-07-13 was still good. I don't remember the exact version of NetBSD-current I was running back then. With NetBSD-current from 2025-01-17, gcov does not report full coverage data after a vfork/exec call. Running the test program inside ktrace shows that after a vfork call, the child process writes its coverage data back, probably right before the exec call, but the parent process doesn't. Running a child process through system(3) is not affected; there, posix_spawn is used instead of vfork/exec. |
| /src/share/mk/ | ||
| H A D | bsd.own.mk | 1.1357 Sat Aug 19 22:58:15 GMT 2023 christos Add elfedit (needed to tag binaries as linux) from GSoC 2023 (Theodore Preduta) |
| /src/distrib/sets/lists/comp/ | ||
| H A D | mi | 1.1357 Fri Jan 08 00:41:33 GMT 2010 pooka Remove documentation for removed macros. |
Completed in 935 milliseconds