Re: test/review: /dev/console logging patch
On 18-Dec-00 Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], John Baldwin writes: On 17-Dec-00 Poul-Henning Kamp wrote: This patch is for the printf(9), log(9) /dev/console stuff. The result is that you can watch the output from /etc/rc in your /var/log/messages. Poul-Henning 1. Replace logwakeup() with msgbuftrigger++; There is little point in calling a function to set a flag. Abstraction to keep other code from having to know the iternals of the log(9) device? Maybe use a #define for logwakeup() that does the msgbuftrigger++ to keep the abstraction w/o the overhead? But it was actually the other way around now :-) It was the log device which had obfuscated the log/printf code because it needed it's assistance to call selwakeup. I want the log/printf code to be as simple as possible, and to have the smallest stack footprint possible... Ok, works for me. :) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
Poul-Henning Kamp wrote: This patch is for the printf(9), log(9) /dev/console stuff. The result is that you can watch the output from /etc/rc in your /var/log/messages. This works spectacularly for me on a UP -current with up to date sources. The only nit I have is that it doesn't understand lines that don't end in a newline very well (such as echo -n, or a printf with no \n), so it produces log output like this: Dec 17 13:00:24 console.info Master /boot/kernel/kernel: /dev/da1s1a: Dec 17 13:00:24 console.info Master /boot/kernel/kernel: FILESYSTEM CLEAN; SKIPPING CHECKS Dec 17 13:00:24 console.info Master /boot/kernel/kernel: /dev/da1s1a: Dec 17 13:00:24 console.info Master /boot/kernel/kernel: clean, 42202 free Dec 17 13:00:24 console.info Master /boot/kernel/kernel: (154 frags, 5256 blocks, 0.2% fragmentation) and Dec 17 13:00:26 console.info Master /boot/kernel/kernel: Doing additional network setup: Dec 17 13:00:26 console.info Master /boot/kernel/kernel: ntpdate Dec 17 13:00:26 console.info Master /boot/kernel/kernel: ntpd Dec 17 13:00:27 console.info Master /boot/kernel/kernel: portmap Dec 17 13:00:27 console.info Master /boot/kernel/kernel: . Now, the first isn't a big deal, but the second is a little confusing. Would there be any harm to changing the dots to something more meaningful, like "Done with additional network setup" on its own line? I seriously considered that when I was working on the echo's last night, but I didn't want to be too revolutionary. :) Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
On Sun, Dec 17, 2000 at 01:15:41PM -0800, Doug Barton wrote: Poul-Henning Kamp wrote: This patch is for the printf(9), log(9) /dev/console stuff. The result is that you can watch the output from /etc/rc in your /var/log/messages. This works spectacularly for me on a UP -current with up to date sources. The only nit I have is that it doesn't understand lines that don't end in a newline very well (such as echo -n, or a printf with no \n), so it produces log output like this: Dec 17 13:00:24 console.info Master /boot/kernel/kernel: /dev/da1s1a: Dec 17 13:00:24 console.info Master /boot/kernel/kernel: FILESYSTEM CLEAN; SKIPPING CHECKS Dec 17 13:00:24 console.info Master /boot/kernel/kernel: /dev/da1s1a: Dec 17 13:00:24 console.info Master /boot/kernel/kernel: clean, 42202 free Dec 17 13:00:24 console.info Master /boot/kernel/kernel: (154 frags, 5256 blocks, 0.2% fragmentation) and Dec 17 13:00:26 console.info Master /boot/kernel/kernel: Doing additional network setup: Dec 17 13:00:26 console.info Master /boot/kernel/kernel: ntpdate Dec 17 13:00:26 console.info Master /boot/kernel/kernel: ntpd Dec 17 13:00:27 console.info Master /boot/kernel/kernel: portmap Dec 17 13:00:27 console.info Master /boot/kernel/kernel: . Now, the first isn't a big deal, but the second is a little confusing. Would there be any harm to changing the dots to something more meaningful, like "Done with additional network setup" on its own line? I seriously considered that when I was working on the echo's last night, but I didn't want to be too revolutionary. :) s/\./(done)/ Or maybe '(finished)'? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: test/review: /dev/console logging patch
On 17-Dec-00 Poul-Henning Kamp wrote: This patch is for the printf(9), log(9) /dev/console stuff. The result is that you can watch the output from /etc/rc in your /var/log/messages. Poul-Henning 1. Replace logwakeup() with msgbuftrigger++; There is little point in calling a function to set a flag. Abstraction to keep other code from having to know the iternals of the log(9) device? Maybe use a #define for logwakeup() that does the msgbuftrigger++ to keep the abstraction w/o the overhead? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
On 17-Dec-00 Doug Barton wrote: Poul-Henning Kamp wrote: This patch is for the printf(9), log(9) /dev/console stuff. The result is that you can watch the output from /etc/rc in your /var/log/messages. This works spectacularly for me on a UP -current with up to date sources. The only nit I have is that it doesn't understand lines that don't end in a newline very well (such as echo -n, or a printf with no \n), so it produces log output like this: Dec 17 13:00:24 console.info Master /boot/kernel/kernel: /dev/da1s1a: Dec 17 13:00:24 console.info Master /boot/kernel/kernel: FILESYSTEM CLEAN; SKIPPING CHECKS Dec 17 13:00:24 console.info Master /boot/kernel/kernel: /dev/da1s1a: Dec 17 13:00:24 console.info Master /boot/kernel/kernel: clean, 42202 free Dec 17 13:00:24 console.info Master /boot/kernel/kernel: (154 frags, 5256 blocks, 0.2% fragmentation) and Dec 17 13:00:26 console.info Master /boot/kernel/kernel: Doing additional network setup: Dec 17 13:00:26 console.info Master /boot/kernel/kernel: ntpdate Dec 17 13:00:26 console.info Master /boot/kernel/kernel: ntpd Dec 17 13:00:27 console.info Master /boot/kernel/kernel: portmap Dec 17 13:00:27 console.info Master /boot/kernel/kernel: . Now, the first isn't a big deal, but the second is a little confusing. Would there be any harm to changing the dots to something more meaningful, like "Done with additional network setup" on its own line? I seriously considered that when I was working on the echo's last night, but I didn't want to be too revolutionary. :) The '.'s are simple and not too cluttery. Fixing the console to line buffer what it sends to log(9) is a better fix, IMO. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
On 2000-Dec-17 15:06:40 -0800, John Baldwin [EMAIL PROTECTED] wrote: On 17-Dec-00 Doug Barton wrote: Would there be any harm to changing the dots to something more meaningful, like "Done with additional network setup" on its own line? The '.'s are simple and not too cluttery. Agreed. I think the current display looks reasonable on the console. I'd prefer to fix the logging patch, rather than clutter up the display. Fixing the console to line buffer what it sends to log(9) is a better fix, IMO. I'm not offering code right now, but how about using a `newline or timeout' approach? If there's a partial line and there's been no console output for some number of seconds, forward the line to log(9). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
Peter Jeremy wrote: On 2000-Dec-17 15:06:40 -0800, John Baldwin [EMAIL PROTECTED] wrote: On 17-Dec-00 Doug Barton wrote: Would there be any harm to changing the dots to something more meaningful, like "Done with additional network setup" on its own line? . Agreed. I think the current display looks reasonable on the console. I'd prefer to fix the logging patch, rather than clutter up the display. ... Which is why I didn't bother changing it. I agree that, "The '.'s are simple and not too cluttery," for someone that has looked at them for years and knows what they mean. They have absolutely no meaning at all to someone who is new to freebsd. I didn't really understand what the different lines and characters signified till I started hacking on rc*, and I'm of somewhat above average intelligence. I will however withdraw my request to change it now, since when the netbsd stuff gets imported things will look much different anyway. Fixing the console to line buffer what it sends to log(9) is a better fix, IMO. Personally I regard these as seperate issues. If someone wants to "fix" the console logger to better respect input with no newline at the end, that is also a desirable goal of course. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
This patch is for the printf(9), log(9) /dev/console stuff. The result is that you can watch the output from /etc/rc in your /var/log/messages. Dec 17 13:00:26 console.info Master /boot/kernel/kernel: Doing additional network setup: Dec 17 13:00:26 console.info Master /boot/kernel/kernel: ntpdate Dec 17 13:00:26 console.info Master /boot/kernel/kernel: ntpd Dec 17 13:00:27 console.info Master /boot/kernel/kernel: portmap Dec 17 13:00:27 console.info Master /boot/kernel/kernel: . The '.'s are simple and not too cluttery. Fixing the console to line buffer what it sends to log(9) is a better fix, IMO. I specifically decided not to do this because I want to be able to see stuff like: echo -n "Press return to avoid disaster: " /dev/console read /dev/console Of course one could add timeouts and what's not, but then imagine the case of two programs writing on /dev/console at the same time... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
In message [EMAIL PROTECTED], John Baldwin writes: On 17-Dec-00 Poul-Henning Kamp wrote: This patch is for the printf(9), log(9) /dev/console stuff. The result is that you can watch the output from /etc/rc in your /var/log/messages. Poul-Henning 1. Replace logwakeup() with msgbuftrigger++; There is little point in calling a function to set a flag. Abstraction to keep other code from having to know the iternals of the log(9) device? Maybe use a #define for logwakeup() that does the msgbuftrigger++ to keep the abstraction w/o the overhead? But it was actually the other way around now :-) It was the log device which had obfuscated the log/printf code because it needed it's assistance to call selwakeup. I want the log/printf code to be as simple as possible, and to have the smallest stack footprint possible... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
In message [EMAIL PROTECTED], Peter Jeremy writes: I'm not offering code right now, but how about using a `newline or timeout' approach? If there's a partial line and there's been no console output for some number of seconds, forward the line to log(9). I played with this, and I was not happy with the result, if somebody else can do it better, I'm open for patches... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
Poul-Henning Kamp wrote: This patch is for the printf(9), log(9) /dev/console stuff. The result is that you can watch the output from /etc/rc in your /var/log/messages. Dec 17 13:00:26 console.info Master /boot/kernel/kernel: Doing additional network setup: Dec 17 13:00:26 console.info Master /boot/kernel/kernel: ntpdate Dec 17 13:00:26 console.info Master /boot/kernel/kernel: ntpd Dec 17 13:00:27 console.info Master /boot/kernel/kernel: portmap Dec 17 13:00:27 console.info Master /boot/kernel/kernel: . The '.'s are simple and not too cluttery. Fixing the console to line buffer what it sends to log(9) is a better fix, IMO. I specifically decided not to do this because I want to be able to see stuff like: echo -n "Press return to avoid disaster: " /dev/console read /dev/console Of course one could add timeouts and what's not, but then imagine the case of two programs writing on /dev/console at the same time... *nod* I wasn't sure that the buffering was the best suggestion, which is why I preferred making the messages from /etc/rc* more meaningful. :) Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
In message [EMAIL PROTECTED], Doug Barton writes: The '.'s are simple and not too cluttery. Fixing the console to line buffer what it sends to log(9) is a better fix, IMO. I specifically decided not to do this because I want to be able to see stuff like: echo -n "Press return to avoid disaster: " /dev/console read /dev/console Of course one could add timeouts and what's not, but then imagine the case of two programs writing on /dev/console at the same time... *nod* I wasn't sure that the buffering was the best suggestion, which is why I preferred making the messages from /etc/rc* more meaningful. :) Just for the record: There is no support for green "OK" messages in my patch :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
