Re: OpenGL-based framebuffer concepts

["Antonino A. Daplas" <adaplas@gmail.com>]

Jon Smirl wrote:
> On 6/1/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Jon Smirl wrote:
>> > On 6/1/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> >> Jon Smirl wrote:
>> >> > On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
>> >> >
>> >>
>> >> Console writes are done with the console semaphore held. printk
>> will also
>> >> just write to the log buffer and defer the actual console printing
>> >> for later, by the next or current process that will grab the
>> semaphore.
>> >
>> > That was my original position too. But Alan Cox has drilled it into me
>> > that this is not acceptable for printks in interrupt context, they
>> > need to print there and not be deferred.
>> >
>>
>> Just to clarify, it's not my position, that's how the current printk code
>> works.
> 
> I haven't looked at the code, but if there is just normal console
> running and nothing like X is around, doesn't the console system
> always have the semaphore? If it always has the semaphore then
> interupt context printk's aren't blocked.
> 
> I think that interrupt context printk's work today, I have definitely
> seen one printk get inserted into the middle of another on my console.
> How else could you achieve that?
> 

foreground calls acquire_console_sem()
foreground process does a printk, printk writes to log buffer
interrupt-> does a printk -> message inserted to log buffer
foreground process calls release_console_sem
release_console_sem() dumps log buffer contents to console driver

Tony