> On 6/7/11 6:33 PM, Dieter BSD wrote:
> >>> I've been working on fixing problems with printf(9), log(9) and
> >>> related functions. Today I tried converting printf(9) to write
> >>> to the log rather than directly to the console, unless the log is
> >>> not open, in which case the message is also sent to the console.
> >>> Printf(...) is now the same as log(LOG_INFO, ...).
> >> oh please no!
> >>
> >> from my perspective, I want my printf output to go to the console.
> >> immediately, regardless of where it goes after that.
> >> I don't care if there is or is not a log.
> >> I do NOT want to EVER have the problem I've had on linux where
> >> the last vital bit of output never made it out before the system stopped.
> >>
> >> once it's been shown on the console I don't care what happens to it..
> > Printfs to the console cause data loss. Easily repeatable.
> > Absolutely unacceptable.
> >
> > You are welcome to fix the actual underlying problem. I would
> > love to see the underlying problem fixed! I've asked a few times
> > before, but I'll ask again. Why does a driver for one piece of
> > hardware have to block interrupts for all hardware? I thought
> > changing from spl to mutex was supposed to fix this?
> >
> > My changes do not prevent a sysadmin from having printf output
> > go to the console, it gives them a choice. Currently there is
> > no choice.
> NO! a kernel printf goes to the console however it may be redirected.
I agree 100%!
file system full ...
> It MAY also decide to go somewhere else.
> But not if it means unreliable delivery to the serial port.
> The console MUST get the output in a completely reliable manner unless
> it's been disabled.
> do not do anything that gets between the console and the problem.
> if you want to send it on to some other secondary sevice such s a log,
> then disable the console and take the priority service but do NOT do
> any of the silly tricks that some people have tried in the past like
> making the console just one of several things on a mux. all with equal
> ability to screw up the other. I want the console to be the last
> refuge in a dying system.
> if a send a char there I KNOW it's gone out. it is synchronous and it
> doesn't lie.
> if you don't want a reliable console then turn it off but don't make
> something else that is unreliable and call it the console.
> call it anything else but don't screw up the console.
>
>
>
>
> >>> I commented out the line in /etc/syslog.conf that sends
> >>> some log messages to the console. In multiuser mode,
> >>> normal printfs go to log, but not the console, as expected.
> >>>
> >>> Bootup messages, shutdown messages, and panic messages all
> >>> show up on the console as expected.
> >>>
> >>> Are there any other special cases to test?
> > _______________________________________________
> > freebsd-hackers@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
> >
> >
>
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
