public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@redhat.com>
To: "Martin J. Bligh" <mbligh@mbligh.org>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, alan@redhat.com
Subject: Re: 2.6.13-mm1
Date: Thu, 1 Sep 2005 10:50:06 -0400	[thread overview]
Message-ID: <20050901145006.GF5427@devserv.devel.redhat.com> (raw)
In-Reply-To: <6970000.1125584568@[10.10.2.4]>

On Thu, Sep 01, 2005 at 07:22:53AM -0700, Martin J. Bligh wrote:
> -               if (count > (TTY_FLIPBUF_SIZE - tty->flip.count))
> -                       count = TTY_FLIPBUF_SIZE - tty->flip.count;
> -
> +               count = tty_buffer_request_room(tty, N_INBUF);
> +               

Should be "int count = " yes

>                 /* If flip is full, just reschedule a later read */
>                 if (count == 0) {
>                         poll_mask |= HVC_POLL_READ;
> 
> shouldn't be deleting the declaration of count. 
> and possibly the "flip removal" was incomplete (line 636) ???

Yep. You can remove the tty->flip.count test or use count, but at that
point count is guaranteed to be > 0 I believe. Fixed both in my tree will
push a new diff to Andre soon.

Also if you are tidying up all the 'read 64 chars and take a break' stuff
should just go away. The kernel will buffer large chunks of data for you
now. In the ideal case if you know the total pending space you can do

	int len = tty_buffer_request_room(tty, len)

and it'll look to kmalloc a big enough buffer for you if the buffer pool
isn't suitable. Even if that fails (its a hint) the tty layer will split the
data across multiple smaller buffers for you when you use tty_insert_flip_*

So you should be able to just ram data at it as it comes off the hvc.

Alan


  reply	other threads:[~2005-09-01 14:50 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-01 10:55 2.6.13-mm1 Andrew Morton
2005-09-01 14:22 ` 2.6.13-mm1 Martin J. Bligh
2005-09-01 14:50   ` Alan Cox [this message]
2005-09-01 20:56     ` 2.6.13-mm1 Joel Schopp
2005-09-01 21:16       ` 2.6.13-mm1 Alan Cox
2005-09-01 21:26         ` 2.6.13-mm1 Joel Schopp
2005-09-01 21:44           ` 2.6.13-mm1 Alan Cox
2005-09-12 16:34             ` tty patches in 2.6.13-mm3 (was Re: 2.6.13-mm1) serue
2005-09-12 16:55               ` Joel Schopp
2005-09-12 17:04             ` 2.6.13-mm1 serue
2005-09-01 14:59   ` 2.6.13-mm1 Adrian Bunk
2005-09-01 15:01 ` [PATCH] mips: remove typedef from struct flock Yoichi Yuasa
2005-09-01 15:38 ` 2.6.13-mm1 Dominik Karall
2005-09-01 16:09   ` 2.6.13-mm1 John Stoffel
2005-09-01 16:28     ` 2.6.13-mm1 Dominik Karall
2005-09-01 17:34       ` 2.6.13-mm1 John Stoffel
2005-09-01 18:05         ` 2.6.13-mm1 Dominik Karall
2005-09-01 18:27           ` 2.6.13-mm1 John Stoffel
2005-09-01 15:44 ` [PATCH] : struct dentry : place d_hash close to d_parent and d_name to speedup lookups Eric Dumazet
2005-09-01 15:48   ` Eric Dumazet
2005-09-01 17:36     ` Dipankar Sarma
2005-09-01 19:52       ` Eric Dumazet
2005-09-01 17:41 ` 2.6.13-mm1 - drivers/isdn/i4l/isdn_tty broken Damir Perisa
2005-09-01 21:06   ` Alan Cox
2005-09-02  1:05   ` 2.6.13-mm1 - drivers/serial/jsm/jsm_tty broken too Damir Perisa
2005-09-01 21:14 ` 2.6.13-mm1: PCMCIA problem Rafael J. Wysocki
2005-09-01 21:28   ` Andrew Morton
2005-09-02  8:30     ` Rafael J. Wysocki
2005-09-02  8:37       ` Rafael J. Wysocki
2005-09-02 10:43         ` Pavel Machek
2005-09-02 10:58           ` Rafael J. Wysocki
2005-09-02 11:09           ` Andrew Morton
2005-09-02 11:45             ` 2.6.13-mm1: swsusp problem (was: PCMCIA problem) Rafael J. Wysocki
2005-09-02 14:17               ` Rafael J. Wysocki
2005-09-04 14:29             ` 2.6.13-mm1: PCMCIA problem Pavel Machek
2005-09-01 22:19 ` 2.6.13-mm1: broken drivers/video/sis/Makefile Adrian Bunk
2005-09-01 23:24   ` Thomas Winischhofer
2005-09-01 23:25 ` 2.6.13-mm1: misc mwave issues Adrian Bunk
2005-09-02 12:36   ` Alan Cox
2005-09-02 13:57 ` 2.6.13-mm1 Benjamin LaHaise
2005-09-02 20:57   ` 2.6.13-mm1 Andrew Morton
2005-09-06 11:50     ` 2.6.13-mm1 Benjamin LaHaise
2005-09-02 14:30 ` 2.6.13-mm1 Alexander Nyberg
2005-09-02 14:40   ` 2.6.13-mm1 Zwane Mwaikambo
2005-09-03 12:21 ` 2.6.13-mm1 Adrian Bunk
2005-09-03 19:34   ` 2.6.13-mm1 Andrew Morton
2005-09-03 19:54     ` 2.6.13-mm1 Adrian Bunk
2005-09-03 20:06       ` 2.6.13-mm1 Andrew Morton
2005-09-04 20:00         ` 2.6.13-mm1 Adrian Bunk
2005-09-04 21:24         ` 2.6.13-mm1 Jesper Juhl
2005-09-04 21:30           ` 2.6.13-mm1 Andrew Morton
2005-09-04 21:36             ` 2.6.13-mm1 Jesper Juhl
2005-09-07  0:05             ` 2.6.13-mm1 Paul Jackson
2005-09-07  0:32               ` 2.6.13-mm1 Andrew Morton
2005-09-07  0:44               ` 2.6.13-mm1 Jesper Juhl
2005-09-07  2:38                 ` 2.6.13-mm1 Paul Jackson
2005-09-04 10:26 ` 2.6.13-mm1 Alexander Nyberg
  -- strict thread matches above, loose matches on Subject: below --
2005-09-01 18:21 2.6.13-mm1 J.A. Magallon
2005-09-01 22:00 ` 2.6.13-mm1 Adrian Bunk
     [not found] <fa.hqupr0d.1u3af35@ifi.uio.no>
2005-09-02  1:39 ` 2.6.13-mm1 Reuben Farrelly
2005-09-02  1:56   ` 2.6.13-mm1 J.A. Magallon
2005-09-02  2:06     ` 2.6.13-mm1 Andrew Morton
2005-09-02 15:53       ` 2.6.13-mm1 J.A. Magallon
2005-09-02 21:45         ` 2.6.13-mm1 Andrew Morton
2005-09-02 22:55           ` 2.6.13-mm1 J.A. Magallon
2005-09-03  0:15           ` 2.6.13-mm1 gcoady
2005-09-02  2:04   ` 2.6.13-mm1 Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050901145006.GF5427@devserv.devel.redhat.com \
    --to=alan@redhat.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@mbligh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox