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.
next prev parent 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®