Re: [PATCH] detour TTY driver - now ttyprintk

[Samo Pogacnik]

On 21.06.2010 (Mon) at 15:38 +0100 Alan Cox wrote:
  I'm thinking to leave the ratelimit support in for the time being. I had
  in mind cases, when someone does
   cat /proc/kmsg  dev/ttyprintk or
  suppose the console is redirected to ttyprintk (which i would like to be
  able to do from user program)
 
 Console as in the printk sense would then loop.
 
 If you are going to do the flow control you should probably do something
 like
 
 
 write_room()
 {
   if (!flow_controlled)
   space = 8192;
   return space;
 }
 
 write()
 {
   space -= len;
 }
 
 then your flow control will behave properly and slow down users rather
 than losing data (except stuff sent without blocking)
 
For correct flow control, i suppose current empty space of the real
(final) printk buffer is needed. On the other hand my intermediate
pre-formatting buffer is only one line long, but serialized on access
in a way that it is always completely available (except for the time of
tpk_printk() function running). As such intermediate buffer only defines
maximum write_room space.

Now there are two ideas. The first one is to dig out current real printk
buffer space (smells like hacking?) and adapt write_room to that space
in some logical manner. And the other would be to use ratelimit support
to switch between max and zero in write_room answer and remove other
retelimit response?

What do you suggest, do i miss something?

regards, Samo

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] detour TTY driver - now ttyprintk

[Alan Cox]

 For correct flow control, i suppose current empty space of the real
 (final) printk buffer is needed. On the other hand my intermediate

Console drivers have their own buffering so that doesn't really work. If
you want to just avoid explosions then you don't need to be quite so
clever

 in some logical manner. And the other would be to use ratelimit support
 to switch between max and zero in write_room answer and remove other
 retelimit response?

Yes - except that a driver isn't permitted to reduce the write room space
by more than bytes written. That is if you offer 512 bytes you can't
offer 0 until 512 bytes have been written - hence the design of the pseudo
code I posted in the previous message.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html