Searched hist:230099 (Results 51 - 63 of 63) sorted by relevance
| /freebsd-11.0-release/etc/rc.d/ | ||
| H A D | watchdogd | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | amd | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | cleartmp | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | ip6addrctl | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | mountd | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | moused | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | ntpd | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | pf | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | sendmail | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | sshd | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | ipfilter | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | nfsd | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
| H A D | jail | diff 230099 Sat Jan 14 02:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps. |
Completed in 134 milliseconds