mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: David VomLehn <dvomlehn@cisco.com>
Cc: Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH] Combine two one-character CR-LF writes into one two-character write for O_ONLCR
Date: Thu, 13 Aug 2009 20:47:19 +0100	[thread overview]
Message-ID: <20090813204719.6c91eaf2@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <20090813184218.GA12832@cuplxvomd02.corp.sa.net>

> Good question. Right now, there are a number of USB serial devices that don't
> use the generic USB serial framework, but they generally seem to use the
> write_urb_busy flag the same way the generic code does. This makes it easier

They all suck, they all misimplement the interfaces. The proper way to do
this is to use a FIFO (kfifo makes it tiny amounts of code) and then
either fire off a new URB whenever one completes or if you are
constrained on urb counts but have over one implement Nagle on it.

> to mix and match generic and non-generic code. Going to a FIFO approach and
> doing away with the write_urb_busy flag seemed like a lot of change for very
> little benefit. In addition, I would argue that doing one two-character write()
> of two one-character writes() is a more logical way to output two characters,
> anyway.

The tty layer requires you can provide some buffering and that your
write_room function doesn't reduce by more than the bytes offered without
them being written. The sane way to do that is to use the kfifo API.

The ONLCR stuff is just a corner case example of where the USB serial
code breaks so the real bug wants fixing.

  reply	other threads:[~2009-08-13 19:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-13 17:54 David VomLehn
2009-08-13 18:15 ` Greg KH
2009-08-13 18:42   ` David VomLehn
2009-08-13 19:47     ` Alan Cox [this message]
2009-08-13 19:50 ` Alan Cox
2009-08-13 19:55   ` David VomLehn
2009-08-13 19:58     ` Alan Cox
2009-08-13 21:27     ` Greg KH

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=20090813204719.6c91eaf2@lxorguk.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=dvomlehn@cisco.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.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

all inboxes | Powered by JetHome®