mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Fortescue <mark@mtfhpc.demon.co.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	sparclinux@vger.kernel.org, joy@entuzijast.net
Subject: Re: Allow 8250 to work on sparc.
Date: Tue, 16 Sep 2008 14:15:43 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.61.0809161343450.25955@mtfhpc.demon.co.uk> (raw)
In-Reply-To: <20080916115400.31522d77@lxorguk.ukuu.org.uk>

Hi Alan,

On Tue, 16 Sep 2008, Alan Cox wrote:

>> I am intrigued. Other than the valid baud rates what differences are
>> visible at the user level?
>
> There are lots of variations between hardware of all kinds but the big
> one with USB devices is generally latency.
>

At the driver level there are lots of varients but I was under the 
impression that at the user level, the interface is common for async 
serial ports.

Latency can be an issue, but can it be read/changed via the user <-> 
kernel interface in a way that is not common to all async serial ports?

If not, it is transparent at the programming interface for user level code 
so the USB serial ports are no different at this level to classic PC AT 
serial ports and as such I see no reason why, in the long run, they should 
not share minor number space.

Taking the argument to its logical conclusion, all devices that have a 
common user <-> kernel interface should have device drivers that are 
capable of sharing minor device number space.

I am sure this discusion will crop up again in the future :).

Regards
 	Mark.

  reply	other threads:[~2008-09-16 13:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-13  4:18 [PATCH 0/2]: " David Miller
2008-09-15 14:26 ` Mark Fortescue
2008-09-15 16:22   ` Alan Cox
2008-09-15 18:51     ` Mark Fortescue
2008-09-16 10:54       ` Alan Cox
2008-09-16 13:15         ` Mark Fortescue [this message]
2008-09-15 18:51     ` David Miller

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=Pine.LNX.4.61.0809161343450.25955@mtfhpc.demon.co.uk \
    --to=mark@mtfhpc.demon.co.uk \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@davemloft.net \
    --cc=joy@entuzijast.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=sparclinux@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®