Messages in this thread | | | Subject | Re: [PATCH] Correctly flush 8250 buffers, notify ldisc of line status changes. | From | Alan Cox <> | Date | Tue, 09 Nov 2004 13:49:19 +0000 |
| |
On Maw, 2004-11-09 at 14:39, David Woodhouse wrote: > Actually I needed it to respond to CTS going away, and it provides a > notification *before* the data are *sent*. Which lets me know that the > first bytes of my packet were dropped by the automatic contention > detection circuitry and I need to flush the rest of the packet from the > FIFO rather than letting the hardware driver wait for CTS to come back > then then send a corrupt half-packet.
But you can't flush the fifo from that callback, you don't have any locking on it. What are you locking semantics ? Define them, versus open, versus close, versus other I/O.
> That solves a different problem, and isn't quite as useful to me. I want > to be able to respond to CTS going low as quickly as possible, by > flushing the rest of the characters from the outgoing queue. I was happy > enough with using a tasklet to actually call the flush method, to avoid > the deadlock you pointed out without changing the locking of all the > hardware drivers).
So you want to replace a tasklet that responds to the event with a tasklet which is called by the event ? Tell me how they differ when low latency is set on the tty - I don't see any difference in performance
> > Andrew - please reject the patch. > > I'll submit the bit which makes the flush_buffer method work on its own. > Alan, would you care to offer a viable alternative which solves the > problem I'm interested in?
If you can't define the locking semantics, its not viable anyway. I see two things we can do usefully here. The first is to teach tty_flip_buffer_push more about urgency - since the new tty code I'm running/crashing/debugging has a real packet queue not just flip buffers we can queue a tiny message to the queue front and we can probably begin to cheat a bit more on low_latency v immediate.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |