Alan Cox <alan@xxxxxxxxxx> writes:
> On Wed, Jun 21, 2006 at 04:16:33PM +0400, Sergei Organov wrote:
>> tty_insert_flip_string(tty, data, length);
>>
>> instead has slightly more chances to transfer 'length' chars as
>> tty_insert_flip_string(), unlike tty_buffer_request_room(), loops to
>> find the memory.
>>
>> Overall, what's the canonical way to transfer 'length' chars from a
>> buffer 'buf' to the tty layer?
>
> tty_insert_flip_string called by itself will try to do the right thing. The
> tty_insert_flip_char interface can benefit a lot from you knowing the ideal
> buffer size to use so its very useful in the case of
>
> int bytes = inw(port->fifo);
> int count = tty_buffer_request_room(tty, bytes);
>
> while(...) {
> tty_insert_flip_char ..
>
> It is also useful if you want a linear buffer for ease of copying.
>
> In the USB case it may be helpful as it will try and allocate blocks
> of memory reflecting the size of the blocks to be pushed to the user
> rather than guessing. As you suggest for most cases it probably makes
> no real difference
Thanks, -- that's the answer I've more or less expected.
One more question, if I get memory for N bytes with
tty_prepare_flip_string() then store M (M <= N) bytes into the buffer,
how do I tell tty layer that only M bytes are in fact stored?
[I'm thinking about eliminating buffers allocation for urbs as well as
data copy when transferring data from USB subsystem to flip buffers of
the tty subsystem. Currently the flow is:
- allocate data buffer for urb.
- submit the urb to USB subsystem.
- copy received data from the buffer to tty (possibly allocating more
buffers in tty)
- deallocate the data buffer
- flip (possibly deallocating some buffers in tty)
and it seems that using tty buffers directly is a better idea:
- allocate N-bytes data buffer from tty and use it for urb
- submit the urb to USB subsystem
- flip M-bytes of data (M <= N) in USB receive callback.
]
--
Sergei.
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
