Searched hist:e (Results 1 - 25 of 7844) sorted by relevance
| /src/sys/arch/arm/imx/ | ||
| H A D | imx50_iomuxreg.h | 1.1 Fri Jul 25 07:49:56 GMT 2014 hkenken branches: 1.1.2; 1.1.6; Add support i.MX50x * i.MX50 series is e-ink e-reader processor. 1.1 Fri Jul 25 07:49:56 GMT 2014 hkenken branches: 1.1.2; 1.1.6; Add support i.MX50x * i.MX50 series is e-ink e-reader processor. |
| H A D | imx51_dpllreg.h | 1.2 Fri Jul 25 07:49:56 GMT 2014 hkenken Add support i.MX50x * i.MX50 series is e-ink e-reader processor. 1.2 Fri Jul 25 07:49:56 GMT 2014 hkenken Add support i.MX50x * i.MX50 series is e-ink e-reader processor. |
| /src/sys/arch/hp300/dev/ | ||
| H A D | mcclock_frodo.c | 1.1 Sat Apr 19 05:37:54 GMT 2014 tsutsui branches: 1.1.2; 1.1.4; 1.1.6; 1.1.8; 1.1.12; 1.1.68; Add proper RealTime Clock support for HP9000/425e. As the OpenBSD/hp300 page says 425e doesn't have the traditional RTC at intio (as it also lacks DCA 16550 serial at intio?), but after a few hour investigation it turns out that 425e uses mc146818 compatible calendar clock in the Apollo "frodo" utility chip and the frodo chip on 425e actually has the 32kHz OSC and is actually backed up by the onboard lithium battery. Tested on HP425e (with mcclock) and HP362 (with old rtc). 1.1 Sat Apr 19 05:37:54 GMT 2014 tsutsui branches: 1.1.2; 1.1.4; 1.1.6; 1.1.8; 1.1.12; 1.1.68; Add proper RealTime Clock support for HP9000/425e. As the OpenBSD/hp300 page says 425e doesn't have the traditional RTC at intio (as it also lacks DCA 16550 serial at intio?), but after a few hour investigation it turns out that 425e uses mc146818 compatible calendar clock in the Apollo "frodo" utility chip and the frodo chip on 425e actually has the 32kHz OSC and is actually backed up by the onboard lithium battery. Tested on HP425e (with mcclock) and HP362 (with old rtc). 1.1 Sat Apr 19 05:37:54 GMT 2014 tsutsui branches: 1.1.2; 1.1.4; 1.1.6; 1.1.8; 1.1.12; 1.1.68; Add proper RealTime Clock support for HP9000/425e. As the OpenBSD/hp300 page says 425e doesn't have the traditional RTC at intio (as it also lacks DCA 16550 serial at intio?), but after a few hour investigation it turns out that 425e uses mc146818 compatible calendar clock in the Apollo "frodo" utility chip and the frodo chip on 425e actually has the 32kHz OSC and is actually backed up by the onboard lithium battery. Tested on HP425e (with mcclock) and HP362 (with old rtc). 1.1 Sat Apr 19 05:37:54 GMT 2014 tsutsui branches: 1.1.2; 1.1.4; 1.1.6; 1.1.8; 1.1.12; 1.1.68; Add proper RealTime Clock support for HP9000/425e. As the OpenBSD/hp300 page says 425e doesn't have the traditional RTC at intio (as it also lacks DCA 16550 serial at intio?), but after a few hour investigation it turns out that 425e uses mc146818 compatible calendar clock in the Apollo "frodo" utility chip and the frodo chip on 425e actually has the 32kHz OSC and is actually backed up by the onboard lithium battery. Tested on HP425e (with mcclock) and HP362 (with old rtc). |
| /src/share/man/man3/ | ||
| H A D | inttypes.3 | 1.2 Fri May 14 02:45:27 GMT 2010 joerg Fix prologue. \\ -> \e |
| /src/sys/arch/alpha/stand/mkbootimage/ | ||
| H A D | Makefile | 1.1 Fri Apr 02 08:40:26 GMT 1999 cgd add mkbootimage, a program to make a bootable image (i.e. prepend a boot block, pad to a block boundary) from a console program (i.e. a boot block, firmware upgrade executable, etc.) 1.1 Fri Apr 02 08:40:26 GMT 1999 cgd add mkbootimage, a program to make a bootable image (i.e. prepend a boot block, pad to a block boundary) from a console program (i.e. a boot block, firmware upgrade executable, etc.) |
| /src/usr.bin/realpath/ | ||
| H A D | realpath.1 | 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. |
| H A D | realpath.c | 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. 1.2 Thu Jul 21 09:47:31 GMT 2022 kre Make realpath(1) compat with the planned (not yet approved) specification for POSIX.8 (its next version). (Should the requirements change, the code here can be updated). This adds two new options. -e and -E -e just tells realpath to do what it has done since it was imported here. -E makes realpath more compatible with the coreutils version, and allows the final component of the path to not exist (the final component after all symlinks have been expanded, not of the arg on the command line - though that one not existing is one case of the more general spec.). POSIX is not going to specify which of those is the default - instead is planning to require users to always explicitly specify one. The default (now) here is -E. This makes us more compat with coreutils. realpath was added in the first place because it is (apparently) used in real world scripts - the more we can support, the better. Note that in all cases where realpath -e succeeds, realpath -E will succeed as well. This means that any uses of "realpath file" that have been working in HEAD will still work. Some cases that would have failed will work (by default) now. |
| /src/sys/arch/newsmips/stand/bootxx/ | ||
| H A D | start.S | 1.2 Thu Oct 12 05:34:29 GMT 2000 onoe Add support to boot on APbus machine (e.g. NWS-5000). |
| /src/lib/libc/gen/ | ||
| H A D | isinff_ieee754.c | 1.1 Thu Mar 04 23:42:39 GMT 2004 kleink * Turn isinf(3) and isnan(3) into C99-style macros. * Make it possible for ports to override these (i.e., VAX). * Remove isnanl(), which was internal to libc only. |
| H A D | isnanf_ieee754.c | 1.1 Thu Mar 04 23:42:39 GMT 2004 kleink * Turn isinf(3) and isnan(3) into C99-style macros. * Make it possible for ports to override these (i.e., VAX). * Remove isnanl(), which was internal to libc only. |
| /src/sys/arch/amd64/compile/ | ||
| H A D | Makefile | 1.1 Sat Apr 26 18:39:33 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| /src/sys/arch/amd64/include/ | ||
| H A D | aout_machdep.h | 1.1 Sat Apr 26 18:39:37 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | apicvar.h | 1.1 Sat Apr 26 18:39:37 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | bios32.h | 1.1 Sat Apr 26 18:39:37 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | bootinfo.h | 1.1 Sat Apr 26 18:39:38 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | cpuvar.h | 1.1 Sat Apr 26 18:39:39 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | endian.h | 1.1 Sat Apr 26 18:39:40 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | float.h | 1.1 Sat Apr 26 18:39:40 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | i82093var.h | 1.1 Sat Apr 26 18:39:41 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | i82489reg.h | 1.1 Sat Apr 26 18:39:41 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | i82489var.h | 1.1 Sat Apr 26 18:39:41 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | i8259.h | 1.1 Sat Apr 26 18:39:41 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | ieee.h | 1.1 Sat Apr 26 18:39:41 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | ieeefp.h | 1.1 Sat Apr 26 18:39:41 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
| H A D | intr.h | 1.1 Sat Apr 26 18:39:42 GMT 2003 fvdl Rename the x86_64 port to amd64, as this is the actual name used for the processor family now. x86_64 is kept as the MACHINE_ARCH value, since it's already widely used (by e.g. the toolchain, etc), and by other operating systems. |
Completed in 125 milliseconds