Date: Mon, 08 Apr 2013 11:38:04 +0200 From: deeptech71 <deeptech71@gmail.com> To: freebsd-current@freebsd.org Subject: Re: Kernel output interleaved on boot Message-ID: <51628FFC.2070501@gmail.com> In-Reply-To: <CAPS9%2BSudbWF9E0ccZXV=bdZmtFBb6Q3c4RZ3z1xgK%2BAmV%2B2qVg@mail.gmail.com> References: <559270951.20130407172227@serebryakov.spb.ru> <5161CAAF.30106@gmail.com> <CAPS9%2BSudbWF9E0ccZXV=bdZmtFBb6Q3c4RZ3z1xgK%2BAmV%2B2qVg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/07/2013 23:20, Andreas Nilsson wrote:
> On Sun, Apr 7, 2013 at 9:36 PM, deeptech71 <deeptech71@gmail.com <mailto:deeptech71@gmail.com>> wrote:
> options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed.
>
> And here I thought that it was added to mitigate the "interspersed output" problem, and I remember that adding to the conf on previous version help address the problem.
And you were right. AFAICT, the problem was that the threads were writing single characters ("putc()ing") at a time, and would get preempted by other such threads in between. Thus, such tasks would get interleaved at character granularity. Proposals were:
(a) use a stack array in printf()'s body to do line buffering; some argued that kernel stack sizes are fairly limited, others argued that this should not be a limitation even on embedded platforms;
(b) allow a printf() task to fully finish before allowing other printf() tasks to start.
The (a) solution was chosen, with an amendment that the array would be specifiable by a kernel configuration option. GENERIC kernels have "options PRINTF_BUFR_SIZE=128".
If the original poster had removed the PRINTF_BUFR_SIZE option from his kernel configuration, then I see his complaint as invalid.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51628FFC.2070501>