lkml.org 
[lkml]   [2007]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
From
Date
On Tue, 2007-04-03 at 15:10 -0700, Brad Boyer wrote:
> I suppose my opinion on this shows that I didn't come from the x86
> side of Linux.

Perhaps, yes -- if you were just an x86 user you'd be unlikely to care
about the issue at all -- mostly because it's never been a problem
there. Not for the reason you imply, but just because the additional
types of serial port you encounter on an x86 machine have always got it
_right_, and had separate names and device numbers rather than abusing
major 64 and 'ttyS%d'.

> The breakdown on this argument seems to have always
> been that the x86 people wanted 8250 to own ttyS* and most others
> wanted it shared.

But why? There's nothing special and magical about the number 64 and the
letters 't' 't' 'y' and 'S'. And if you have broken software which only
works with ttyS[0123] then you can still create device nodes or symlinks
to work around that.

If you're on a platform where 8250 serial ports _cannot_ exist, then
abusing the 8250 driver's numbers would perhaps be workable, if a little
strange -- but 8250 ports are ubiquitous. You can attach them to just
about anything, of any architecture, that Linux runs on. Except perhaps
S390.

Yes, it would be theoretically possible to come up with a way to share
minor numbers so we can use 'ttyS0' for the first serial port regardless
of what type of port it is. We could take the arch-specific hack that
SPARC has and try to move it to generic code. But what's the point?

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-04-04 02:57    [W:0.102 / U:2.916 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site