Searched hist:1.342 (Results 1 - 25 of 81) sorted by relevance
| /src/sys/arch/alpha/conf/ | ||
| H A D | GENERIC | 1.342 Tue Nov 22 21:24:53 GMT 2011 tls branches: 1.342.2; The rnd pseudo-device is not really optional, because it is in the same source file as the entropy-pool code itself. Move it to std. This will be cleaned up more when I split the sources up as they should be. This fixes build breaks on several ports. Thanks to Havard Eidnes for pointing them out. 1.342 Tue Nov 22 21:24:53 GMT 2011 tls branches: 1.342.2; The rnd pseudo-device is not really optional, because it is in the same source file as the entropy-pool code itself. Move it to std. This will be cleaned up more when I split the sources up as they should be. This fixes build breaks on several ports. Thanks to Havard Eidnes for pointing them out. |
| /src/ | ||
| H A D | build.sh | 1.342 Tue Jun 30 21:22:19 GMT 2020 riastradh New build.sh option: -c <compiler> Could never remember what the incantation is to do a clang build, so now it's just `build.sh -c clang'. 1.342 Tue Jun 30 21:22:19 GMT 2020 riastradh New build.sh option: -c <compiler> Could never remember what the incantation is to do a clang build, so now it's just `build.sh -c clang'. |
| H A D | UPDATING | 1.342 Wed Jul 19 17:49:40 GMT 2023 martin Warn to clean gcc objectdirs for updated compiler. 1.342 Wed Jul 19 17:49:40 GMT 2023 martin Warn to clean gcc objectdirs for updated compiler. 1.342 Wed Jul 19 17:49:40 GMT 2023 martin Warn to clean gcc objectdirs for updated compiler. 1.342 Wed Jul 19 17:49:40 GMT 2023 martin Warn to clean gcc objectdirs for updated compiler. |
| /src/distrib/sets/lists/debug/ | ||
| H A D | shl.mi | 1.342 Mon Jun 10 07:47:06 GMT 2024 kre branches: 1.342.2; Correct a typo in libarchive set list updates for recent libarchive update And add me to the list of people who believe that the current 99999 different debugN/ad.arch stuff is a disaster. 1.342 Mon Jun 10 07:47:06 GMT 2024 kre branches: 1.342.2; Correct a typo in libarchive set list updates for recent libarchive update And add me to the list of people who believe that the current 99999 different debugN/ad.arch stuff is a disaster. 1.342 Mon Jun 10 07:47:06 GMT 2024 kre branches: 1.342.2; Correct a typo in libarchive set list updates for recent libarchive update And add me to the list of people who believe that the current 99999 different debugN/ad.arch stuff is a disaster. 1.342 Mon Jun 10 07:47:06 GMT 2024 kre branches: 1.342.2; Correct a typo in libarchive set list updates for recent libarchive update And add me to the list of people who believe that the current 99999 different debugN/ad.arch stuff is a disaster. 1.342 Mon Jun 10 07:47:06 GMT 2024 kre branches: 1.342.2; Correct a typo in libarchive set list updates for recent libarchive update And add me to the list of people who believe that the current 99999 different debugN/ad.arch stuff is a disaster. 1.342 Mon Jun 10 07:47:06 GMT 2024 kre branches: 1.342.2; Correct a typo in libarchive set list updates for recent libarchive update And add me to the list of people who believe that the current 99999 different debugN/ad.arch stuff is a disaster. 1.342 Mon Jun 10 07:47:06 GMT 2024 kre branches: 1.342.2; Correct a typo in libarchive set list updates for recent libarchive update And add me to the list of people who believe that the current 99999 different debugN/ad.arch stuff is a disaster. 1.342 Mon Jun 10 07:47:06 GMT 2024 kre branches: 1.342.2; Correct a typo in libarchive set list updates for recent libarchive update And add me to the list of people who believe that the current 99999 different debugN/ad.arch stuff is a disaster. 1.342 Mon Jun 10 07:47:06 GMT 2024 kre branches: 1.342.2; Correct a typo in libarchive set list updates for recent libarchive update And add me to the list of people who believe that the current 99999 different debugN/ad.arch stuff is a disaster. 1.342 Mon Jun 10 07:47:06 GMT 2024 kre branches: 1.342.2; Correct a typo in libarchive set list updates for recent libarchive update And add me to the list of people who believe that the current 99999 different debugN/ad.arch stuff is a disaster. |
| /src/sys/arch/alpha/alpha/ | ||
| H A D | machdep.c | 1.342 Wed Sep 12 02:00:53 GMT 2012 manu branches: 1.342.2; 1.342.4; setcontext() used to be incompatible with -lpthread since it affected the TLS pointer, therefore wrecking the pthread environement. Some ports had _UC_TLSBASE flag or equivalent (_UC_UNIQUE on alpha) that controlled whether setcontext() would change the TLS pointer. This change let libpthread override setcontext() with its own version that unsets _UC_TLSBASE, enabling safe usage of setcontext() with -lpthread. We also have the following required changes here: - rename alpha's _UC_UNIQUE into _UC_TLSBASE - add _UC_TLSBASE definition in header file for all ports (powerpc, sh3, sparc and sparc64 lack the implementation for now) - introduce a libc stub that can be overriden for setcontext() - modify MD libcs swapcontext() implementations so that they use the setcontext() libc stub instead of doing a plain system call. While we are there: - document various MD _UC_* flags in header file - add libc and libpthread tests for swapcontext() behavior (hopefully helpful to spot MD problems introduced with this change) Future work: - Deciding whether kernel support or _UC_TLSBASE should be added for powerpc, sh3, sparc and sparc64 is left to portmasters sparc64 Approved by core@ 1.342 Wed Sep 12 02:00:53 GMT 2012 manu branches: 1.342.2; 1.342.4; setcontext() used to be incompatible with -lpthread since it affected the TLS pointer, therefore wrecking the pthread environement. Some ports had _UC_TLSBASE flag or equivalent (_UC_UNIQUE on alpha) that controlled whether setcontext() would change the TLS pointer. This change let libpthread override setcontext() with its own version that unsets _UC_TLSBASE, enabling safe usage of setcontext() with -lpthread. We also have the following required changes here: - rename alpha's _UC_UNIQUE into _UC_TLSBASE - add _UC_TLSBASE definition in header file for all ports (powerpc, sh3, sparc and sparc64 lack the implementation for now) - introduce a libc stub that can be overriden for setcontext() - modify MD libcs swapcontext() implementations so that they use the setcontext() libc stub instead of doing a plain system call. While we are there: - document various MD _UC_* flags in header file - add libc and libpthread tests for swapcontext() behavior (hopefully helpful to spot MD problems introduced with this change) Future work: - Deciding whether kernel support or _UC_TLSBASE should be added for powerpc, sh3, sparc and sparc64 is left to portmasters sparc64 Approved by core@ 1.342 Wed Sep 12 02:00:53 GMT 2012 manu branches: 1.342.2; 1.342.4; setcontext() used to be incompatible with -lpthread since it affected the TLS pointer, therefore wrecking the pthread environement. Some ports had _UC_TLSBASE flag or equivalent (_UC_UNIQUE on alpha) that controlled whether setcontext() would change the TLS pointer. This change let libpthread override setcontext() with its own version that unsets _UC_TLSBASE, enabling safe usage of setcontext() with -lpthread. We also have the following required changes here: - rename alpha's _UC_UNIQUE into _UC_TLSBASE - add _UC_TLSBASE definition in header file for all ports (powerpc, sh3, sparc and sparc64 lack the implementation for now) - introduce a libc stub that can be overriden for setcontext() - modify MD libcs swapcontext() implementations so that they use the setcontext() libc stub instead of doing a plain system call. While we are there: - document various MD _UC_* flags in header file - add libc and libpthread tests for swapcontext() behavior (hopefully helpful to spot MD problems introduced with this change) Future work: - Deciding whether kernel support or _UC_TLSBASE should be added for powerpc, sh3, sparc and sparc64 is left to portmasters sparc64 Approved by core@ 1.342 Wed Sep 12 02:00:53 GMT 2012 manu branches: 1.342.2; 1.342.4; setcontext() used to be incompatible with -lpthread since it affected the TLS pointer, therefore wrecking the pthread environement. Some ports had _UC_TLSBASE flag or equivalent (_UC_UNIQUE on alpha) that controlled whether setcontext() would change the TLS pointer. This change let libpthread override setcontext() with its own version that unsets _UC_TLSBASE, enabling safe usage of setcontext() with -lpthread. We also have the following required changes here: - rename alpha's _UC_UNIQUE into _UC_TLSBASE - add _UC_TLSBASE definition in header file for all ports (powerpc, sh3, sparc and sparc64 lack the implementation for now) - introduce a libc stub that can be overriden for setcontext() - modify MD libcs swapcontext() implementations so that they use the setcontext() libc stub instead of doing a plain system call. While we are there: - document various MD _UC_* flags in header file - add libc and libpthread tests for swapcontext() behavior (hopefully helpful to spot MD problems introduced with this change) Future work: - Deciding whether kernel support or _UC_TLSBASE should be added for powerpc, sh3, sparc and sparc64 is left to portmasters sparc64 Approved by core@ 1.342 Wed Sep 12 02:00:53 GMT 2012 manu branches: 1.342.2; 1.342.4; setcontext() used to be incompatible with -lpthread since it affected the TLS pointer, therefore wrecking the pthread environement. Some ports had _UC_TLSBASE flag or equivalent (_UC_UNIQUE on alpha) that controlled whether setcontext() would change the TLS pointer. This change let libpthread override setcontext() with its own version that unsets _UC_TLSBASE, enabling safe usage of setcontext() with -lpthread. We also have the following required changes here: - rename alpha's _UC_UNIQUE into _UC_TLSBASE - add _UC_TLSBASE definition in header file for all ports (powerpc, sh3, sparc and sparc64 lack the implementation for now) - introduce a libc stub that can be overriden for setcontext() - modify MD libcs swapcontext() implementations so that they use the setcontext() libc stub instead of doing a plain system call. While we are there: - document various MD _UC_* flags in header file - add libc and libpthread tests for swapcontext() behavior (hopefully helpful to spot MD problems introduced with this change) Future work: - Deciding whether kernel support or _UC_TLSBASE should be added for powerpc, sh3, sparc and sparc64 is left to portmasters sparc64 Approved by core@ 1.342 Wed Sep 12 02:00:53 GMT 2012 manu branches: 1.342.2; 1.342.4; setcontext() used to be incompatible with -lpthread since it affected the TLS pointer, therefore wrecking the pthread environement. Some ports had _UC_TLSBASE flag or equivalent (_UC_UNIQUE on alpha) that controlled whether setcontext() would change the TLS pointer. This change let libpthread override setcontext() with its own version that unsets _UC_TLSBASE, enabling safe usage of setcontext() with -lpthread. We also have the following required changes here: - rename alpha's _UC_UNIQUE into _UC_TLSBASE - add _UC_TLSBASE definition in header file for all ports (powerpc, sh3, sparc and sparc64 lack the implementation for now) - introduce a libc stub that can be overriden for setcontext() - modify MD libcs swapcontext() implementations so that they use the setcontext() libc stub instead of doing a plain system call. While we are there: - document various MD _UC_* flags in header file - add libc and libpthread tests for swapcontext() behavior (hopefully helpful to spot MD problems introduced with this change) Future work: - Deciding whether kernel support or _UC_TLSBASE should be added for powerpc, sh3, sparc and sparc64 is left to portmasters sparc64 Approved by core@ |
| /src/sys/kern/ | ||
| H A D | init_sysent.c | 1.342 Sun May 19 22:27:15 GMT 2024 christos regen |
| H A D | vfs_subr.c | 1.368 Thu Feb 05 13:37:24 GMT 2009 enami branches: 1.368.2; Make revoke(2) works as before: - vfs_syscalls.c rev. 1.342 fails to invert condition correcly when then-clause and else-clause is swapped. Since then, revoke(2) fails if it is issued by file owner. - Probably since rev. 1.160 of genfs_vnops.c, revoke(2) fails if it is applied to non-device file and drops kernel into ddb. 1.342 Tue May 06 00:37:04 GMT 2008 ad PR kern/38141 lookup/vfs_busy acquire rwlock recursively getvnode: Use vfs_trybusy, not vfs_busy. If unmount is in progress we could deadlock, because vnode locks can be held during getnewvnode(). dounmount() locks in the reverse order (vfs_busy -> vnode). |
| H A D | kern_synch.c | 1.342 Sun Feb 23 16:27:09 GMT 2020 ad kpause(): is only awoken via timeout or signal, so use SOBJ_SLEEPQ_NULL like _lwp_park() does, and dispense with the hashed sleepq & lock. |
| /src/doc/ | ||
| H A D | BRANCHES | 1.342 Sun Jun 04 07:17:09 GMT 2017 snj note netbsd-8 |
| /src/sys/ufs/ffs/ | ||
| H A D | ffs_vfsops.c | 1.342 Tue Dec 27 10:54:38 GMT 2016 hannken branches: 1.342.2; Fix a bug introduced with Rev. 1.294: use LK_NOWAIT when called with MNT_LAZY. 1.342 Tue Dec 27 10:54:38 GMT 2016 hannken branches: 1.342.2; Fix a bug introduced with Rev. 1.294: use LK_NOWAIT when called with MNT_LAZY. |
| /src/sys/arch/arm/arm32/ | ||
| H A D | pmap.c | 1.342 Fri Dec 23 07:15:27 GMT 2016 cherry branches: 1.342.2; "Make NetBSD great again!" Introduce uvm_hotplug(9) to the kernel. Many thanks, in no particular order to: TNF, for funding the project. Chuck Silvers - for multiple API reviews and feedback. Nick Hudson - for testing on multiple architectures and bugfix patches. Everyone who helped with boot testing. KeK (http://www.kek.org.in) for hosting the primary developers. 1.342 Fri Dec 23 07:15:27 GMT 2016 cherry branches: 1.342.2; "Make NetBSD great again!" Introduce uvm_hotplug(9) to the kernel. Many thanks, in no particular order to: TNF, for funding the project. Chuck Silvers - for multiple API reviews and feedback. Nick Hudson - for testing on multiple architectures and bugfix patches. Everyone who helped with boot testing. KeK (http://www.kek.org.in) for hosting the primary developers. |
| /src/sys/dev/scsipi/ | ||
| H A D | cd.c | 1.342 Mon Sep 03 16:29:33 GMT 2018 riastradh branches: 1.342.4; Rename min/max -> uimin/uimax for better honesty. These functions are defined on unsigned int. The generic name min/max should not silently truncate to 32 bits on 64-bit systems. This is purely a name change -- no functional change intended. HOWEVER! Some subsystems have #define min(a, b) ((a) < (b) ? (a) : (b)) #define max(a, b) ((a) > (b) ? (a) : (b)) even though our standard name for that is MIN/MAX. Although these may invite multiple evaluation bugs, these do _not_ cause integer truncation. To avoid `fixing' these cases, I first changed the name in libkern, and then compile-tested every file where min/max occurred in order to confirm that it failed -- and thus confirm that nothing shadowed min/max -- before changing it. I have left a handful of bootloaders that are too annoying to compile-test, and some dead code: cobalt ews4800mips hp300 hppa ia64 luna68k vax acorn32/if_ie.c (not included in any kernels) macppc/if_gm.c (superseded by gem(4)) It should be easy to fix the fallout once identified -- this way of doing things fails safe, and the goal here, after all, is to _avoid_ silent integer truncations, not introduce them. Maybe one day we can reintroduce min/max as type-generic things that never silently truncate. But we should avoid doing that for a while, so that existing code has a chance to be detected by the compiler for conversion to uimin/uimax without changing the semantics until we can properly audit it all. (Who knows, maybe in some cases integer truncation is actually intended!) 1.342 Mon Sep 03 16:29:33 GMT 2018 riastradh branches: 1.342.4; Rename min/max -> uimin/uimax for better honesty. These functions are defined on unsigned int. The generic name min/max should not silently truncate to 32 bits on 64-bit systems. This is purely a name change -- no functional change intended. HOWEVER! Some subsystems have #define min(a, b) ((a) < (b) ? (a) : (b)) #define max(a, b) ((a) > (b) ? (a) : (b)) even though our standard name for that is MIN/MAX. Although these may invite multiple evaluation bugs, these do _not_ cause integer truncation. To avoid `fixing' these cases, I first changed the name in libkern, and then compile-tested every file where min/max occurred in order to confirm that it failed -- and thus confirm that nothing shadowed min/max -- before changing it. I have left a handful of bootloaders that are too annoying to compile-test, and some dead code: cobalt ews4800mips hp300 hppa ia64 luna68k vax acorn32/if_ie.c (not included in any kernels) macppc/if_gm.c (superseded by gem(4)) It should be easy to fix the fallout once identified -- this way of doing things fails safe, and the goal here, after all, is to _avoid_ silent integer truncations, not introduce them. Maybe one day we can reintroduce min/max as type-generic things that never silently truncate. But we should avoid doing that for a while, so that existing code has a chance to be detected by the compiler for conversion to uimin/uimax without changing the semantics until we can properly audit it all. (Who knows, maybe in some cases integer truncation is actually intended!) 1.342 Mon Sep 03 16:29:33 GMT 2018 riastradh branches: 1.342.4; Rename min/max -> uimin/uimax for better honesty. These functions are defined on unsigned int. The generic name min/max should not silently truncate to 32 bits on 64-bit systems. This is purely a name change -- no functional change intended. HOWEVER! Some subsystems have #define min(a, b) ((a) < (b) ? (a) : (b)) #define max(a, b) ((a) > (b) ? (a) : (b)) even though our standard name for that is MIN/MAX. Although these may invite multiple evaluation bugs, these do _not_ cause integer truncation. To avoid `fixing' these cases, I first changed the name in libkern, and then compile-tested every file where min/max occurred in order to confirm that it failed -- and thus confirm that nothing shadowed min/max -- before changing it. I have left a handful of bootloaders that are too annoying to compile-test, and some dead code: cobalt ews4800mips hp300 hppa ia64 luna68k vax acorn32/if_ie.c (not included in any kernels) macppc/if_gm.c (superseded by gem(4)) It should be easy to fix the fallout once identified -- this way of doing things fails safe, and the goal here, after all, is to _avoid_ silent integer truncations, not introduce them. Maybe one day we can reintroduce min/max as type-generic things that never silently truncate. But we should avoid doing that for a while, so that existing code has a chance to be detected by the compiler for conversion to uimin/uimax without changing the semantics until we can properly audit it all. (Who knows, maybe in some cases integer truncation is actually intended!) 1.342 Mon Sep 03 16:29:33 GMT 2018 riastradh branches: 1.342.4; Rename min/max -> uimin/uimax for better honesty. These functions are defined on unsigned int. The generic name min/max should not silently truncate to 32 bits on 64-bit systems. This is purely a name change -- no functional change intended. HOWEVER! Some subsystems have #define min(a, b) ((a) < (b) ? (a) : (b)) #define max(a, b) ((a) > (b) ? (a) : (b)) even though our standard name for that is MIN/MAX. Although these may invite multiple evaluation bugs, these do _not_ cause integer truncation. To avoid `fixing' these cases, I first changed the name in libkern, and then compile-tested every file where min/max occurred in order to confirm that it failed -- and thus confirm that nothing shadowed min/max -- before changing it. I have left a handful of bootloaders that are too annoying to compile-test, and some dead code: cobalt ews4800mips hp300 hppa ia64 luna68k vax acorn32/if_ie.c (not included in any kernels) macppc/if_gm.c (superseded by gem(4)) It should be easy to fix the fallout once identified -- this way of doing things fails safe, and the goal here, after all, is to _avoid_ silent integer truncations, not introduce them. Maybe one day we can reintroduce min/max as type-generic things that never silently truncate. But we should avoid doing that for a while, so that existing code has a chance to be detected by the compiler for conversion to uimin/uimax without changing the semantics until we can properly audit it all. (Who knows, maybe in some cases integer truncation is actually intended!) |
| H A D | sd.c | 1.342 Sun Mar 02 14:13:22 GMT 2025 riastradh sd(4): Break overlong lines. No functional change intended. |
| /src/sys/dev/pci/ | ||
| H A D | if_bge.c | 1.342 Mon Nov 25 05:35:26 GMT 2019 msaitoh branches: 1.342.2; Modify PHY initialization code. This change fix a bug that SK-9D21 doesn't detect MII PHY. - Add error check to bge_miibus_writereg(). - Change return value of bge_miibus_readreg() when a read error occurred. It also add error message using with aprint_debug_dev(). This error occurs on some devices while detecting MII devices. - Move the location of BGE_MI_MODE register's initialization to next to bge_chipinit(). - Set BGE_MAC_MODE before calling ifmedia_init() and/or mii_attach(). - Add retry code for mii_attach() failed. Same as FreeBSD. 1.342 Mon Nov 25 05:35:26 GMT 2019 msaitoh branches: 1.342.2; Modify PHY initialization code. This change fix a bug that SK-9D21 doesn't detect MII PHY. - Add error check to bge_miibus_writereg(). - Change return value of bge_miibus_readreg() when a read error occurred. It also add error message using with aprint_debug_dev(). This error occurs on some devices while detecting MII devices. - Move the location of BGE_MI_MODE register's initialization to next to bge_chipinit(). - Set BGE_MAC_MODE before calling ifmedia_init() and/or mii_attach(). - Add retry code for mii_attach() failed. Same as FreeBSD. |
| H A D | pcidevs.h | 1.342 Sat Jun 30 01:04:25 GMT 2001 thorpej branches: 1.342.2; Regen. 1.342 Sat Jun 30 01:04:25 GMT 2001 thorpej branches: 1.342.2; Regen. 1.342 Sat Jun 30 01:04:25 GMT 2001 thorpej branches: 1.342.2; Regen. 1.342 Sat Jun 30 01:04:25 GMT 2001 thorpej branches: 1.342.2; Regen. 1.342 Sat Jun 30 01:04:25 GMT 2001 thorpej branches: 1.342.2; Regen. 1.342 Sat Jun 30 01:04:25 GMT 2001 thorpej branches: 1.342.2; Regen. 1.342 Sat Jun 30 01:04:25 GMT 2001 thorpej branches: 1.342.2; Regen. 1.342 Sat Jun 30 01:04:25 GMT 2001 thorpej branches: 1.342.2; Regen. |
| /src/sys/uvm/ | ||
| H A D | uvm_map.c | 1.342 Thu Dec 01 02:09:03 GMT 2016 mrg branches: 1.342.2; allow the sizes of the maphist and pdhist to be set in the config file via UVMHIST_MAPHIST_SIZE and UVMHIST_PDHIST_SIZE. 1.342 Thu Dec 01 02:09:03 GMT 2016 mrg branches: 1.342.2; allow the sizes of the maphist and pdhist to be set in the config file via UVMHIST_MAPHIST_SIZE and UVMHIST_PDHIST_SIZE. 1.342 Thu Dec 01 02:09:03 GMT 2016 mrg branches: 1.342.2; allow the sizes of the maphist and pdhist to be set in the config file via UVMHIST_MAPHIST_SIZE and UVMHIST_PDHIST_SIZE. 1.342 Thu Dec 01 02:09:03 GMT 2016 mrg branches: 1.342.2; allow the sizes of the maphist and pdhist to be set in the config file via UVMHIST_MAPHIST_SIZE and UVMHIST_PDHIST_SIZE. 1.342 Thu Dec 01 02:09:03 GMT 2016 mrg branches: 1.342.2; allow the sizes of the maphist and pdhist to be set in the config file via UVMHIST_MAPHIST_SIZE and UVMHIST_PDHIST_SIZE. 1.342 Thu Dec 01 02:09:03 GMT 2016 mrg branches: 1.342.2; allow the sizes of the maphist and pdhist to be set in the config file via UVMHIST_MAPHIST_SIZE and UVMHIST_PDHIST_SIZE. |
| /src/sys/arch/sparc/sparc/ | ||
| H A D | machdep.c | 1.342 Sat Apr 19 01:32:42 GMT 2025 riastradh sparc: Load the signal handler _before_ resetting it, not after. Should fix SA_RESETHAND. PR port-sparc/59323: t_sigaction:sigaction_resethand test is failing |
| /src/sys/arch/macppc/conf/ | ||
| H A D | GENERIC | 1.342 Fri Feb 23 03:04:01 GMT 2018 sevan Enable BUFQ_PRIOCSCAN by default for NetBSD/macppc. Drop references to NEW_BUFQ_STRATEGY and replace with currently available options BUFQ_READPRIO and BUFQ_PRIOCSCAN. ok <macallan> |
| /src/share/misc/ | ||
| H A D | acronyms.comp | 1.342 Wed Mar 01 11:12:56 GMT 2023 fcambus Add RAII (resource acquisition is initialization). 1.342 Wed Mar 01 11:12:56 GMT 2023 fcambus Add RAII (resource acquisition is initialization). 1.342 Wed Mar 01 11:12:56 GMT 2023 fcambus Add RAII (resource acquisition is initialization). 1.342 Wed Mar 01 11:12:56 GMT 2023 fcambus Add RAII (resource acquisition is initialization). |
| /src/distrib/sets/lists/comp/ | ||
| H A D | shl.mi | 1.342 Tue Sep 15 06:22:33 GMT 2020 mrg mark tsan files as !machine=sparc64. 1.342 Tue Sep 15 06:22:33 GMT 2020 mrg mark tsan files as !machine=sparc64. 1.342 Tue Sep 15 06:22:33 GMT 2020 mrg mark tsan files as !machine=sparc64. 1.342 Tue Sep 15 06:22:33 GMT 2020 mrg mark tsan files as !machine=sparc64. |
| /src/usr.bin/make/unit-tests/ | ||
| H A D | Makefile | 1.342 Sun Jan 07 02:07:44 GMT 2024 sjg make: unit-tests handle TEST_MAKE:T != make We need to allow for ${TEST_MAKE:T}[1-9]: etc when TEST_MAKE is not 'make' 1.342 Sun Jan 07 02:07:44 GMT 2024 sjg make: unit-tests handle TEST_MAKE:T != make We need to allow for ${TEST_MAKE:T}[1-9]: etc when TEST_MAKE is not 'make' |
| /src/sys/arch/sparc64/sparc64/ | ||
| H A D | locore.s | 1.342 Thu Nov 08 00:34:38 GMT 2012 macallan use system tick timer instead of %tick on UltraSPARC-III-ish CPUs review & fixes by Takeshi Nakayama |
| /src/sys/dev/ata/ | ||
| H A D | wd.c | 1.342 Sun Jul 29 00:50:19 GMT 2007 ad It's not a good idea for device drivers to modify b_flags, as they don't need to understand the locking around that field. Instead of setting B_ERROR, set b_error instead. b_error is 'owned' by whoever completes the I/O request. |
| /src/sys/arch/i386/conf/ | ||
| H A D | ALL | 1.342 Sat Aug 04 04:39:40 GMT 2012 riastradh Add uatp(4) to i386 ALL kernel configuration. |
| H A D | files.i386 | 1.342 Sat Feb 14 20:22:59 GMT 2009 cube Don't set version deep in the source tree if it's older than the one in conf/files. |
Completed in 1707 milliseconds