On Tue, Aug 14, David Woodhouse wrote:
> On Tue, 2007-08-14 at 13:49 +0200, Olaf Hering wrote:
> > On Wed, Apr 04, Paul Mackerras wrote:
> >
> > > David Woodhouse writes:
> > >
> > > > There are proper device numbers registered for pmac_zilog now. Use them.
> >
> > Which numbers?
>
>
On Tue, 2007-08-14 at 13:49 +0200, Olaf Hering wrote:
> On Wed, Apr 04, Paul Mackerras wrote:
>
> > David Woodhouse writes:
> >
> > > There are proper device numbers registered for pmac_zilog now. Use them.
>
> Which numbers?
shinybook /shiny/git/mtd-utils $ ls -l /dev/ttyPZ*
crw-rw 1 root
On Wed, Apr 04, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > There are proper device numbers registered for pmac_zilog now. Use them.
Which numbers?
> Sigh. I guess this is inevitable, but IMNSHO this exposes a weakness
> in our serial subsystem.
So, when will the name of pmac_zilog
On Wed, Apr 04, Paul Mackerras wrote:
David Woodhouse writes:
There are proper device numbers registered for pmac_zilog now. Use them.
Which numbers?
Sigh. I guess this is inevitable, but IMNSHO this exposes a weakness
in our serial subsystem.
So, when will the name of pmac_zilog get
On Tue, 2007-08-14 at 13:49 +0200, Olaf Hering wrote:
On Wed, Apr 04, Paul Mackerras wrote:
David Woodhouse writes:
There are proper device numbers registered for pmac_zilog now. Use them.
Which numbers?
shinybook /shiny/git/mtd-utils $ ls -l /dev/ttyPZ*
crw-rw 1 root uucp 204,
On Tue, Aug 14, David Woodhouse wrote:
On Tue, 2007-08-14 at 13:49 +0200, Olaf Hering wrote:
On Wed, Apr 04, Paul Mackerras wrote:
David Woodhouse writes:
There are proper device numbers registered for pmac_zilog now. Use them.
Which numbers?
shinybook
On Thu, 12 Apr 2007, David Lang wrote:
> On Thu, 12 Apr 2007, Gerhard Mack wrote:
> > Sometimes it's not the speed it's the cost.. The best I've ever done is
> > 5.5 interfaces per u/ Although with a better motherboard and case it might
> > have been different.
>
> I have a bunch of servers from
On Thu, 12 Apr 2007, David Lang wrote:
On Thu, 12 Apr 2007, Gerhard Mack wrote:
Sometimes it's not the speed it's the cost.. The best I've ever done is
5.5 interfaces per u/ Although with a better motherboard and case it might
have been different.
I have a bunch of servers from rackable,
s any address not assigned to
that port)
On Thu, 12 Apr 2007, Roland Dreier wrote:
Date: Thu, 12 Apr 2007 08:34:40 -0700
From: Roland Dreier <[EMAIL PROTECTED]>
To: Benny Amorsen <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PATCH] Stop pmac_zilog from abus
to
that port)
On Thu, 12 Apr 2007, Roland Dreier wrote:
> Date: Thu, 12 Apr 2007 08:34:40 -0700
> From: Roland Dreier <[EMAIL PROTECTED]>
> To: Benny Amorsen <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: [PATCH] Stop pmac_zilog from ab
> Indeed, port density is disappointingly poor in modern servers. Do you
> know any with more than 14 ports per U? (That's an MBX 1U server with
> 8 on-board and a 6-port expansion).
If you really need a ton of ports you could probably build a 1U server
with 2 * 2-port 10gig NICs, and use
Indeed, port density is disappointingly poor in modern servers. Do you
know any with more than 14 ports per U? (That's an MBX 1U server with
8 on-board and a 6-port expansion).
If you really need a ton of ports you could probably build a 1U server
with 2 * 2-port 10gig NICs, and use
to
that port)
On Thu, 12 Apr 2007, Roland Dreier wrote:
Date: Thu, 12 Apr 2007 08:34:40 -0700
From: Roland Dreier [EMAIL PROTECTED]
To: Benny Amorsen [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
Indeed
address not assigned to
that port)
On Thu, 12 Apr 2007, Roland Dreier wrote:
Date: Thu, 12 Apr 2007 08:34:40 -0700
From: Roland Dreier [EMAIL PROTECTED]
To: Benny Amorsen [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device
> "GM" == Gerhard Mack <[EMAIL PROTECTED]> writes:
GM> On Wed, 4 Apr 2007, Alan Cox wrote:
>> You don't get machines with 64 ethernet ports on add-in cards.
>> There are good reasons for the naming schemes in use.
GM> If they made them I'd build one.
Indeed, port density is disappointingly
GM == Gerhard Mack [EMAIL PROTECTED] writes:
GM On Wed, 4 Apr 2007, Alan Cox wrote:
You don't get machines with 64 ethernet ports on add-in cards.
There are good reasons for the naming schemes in use.
GM If they made them I'd build one.
Indeed, port density is disappointingly poor in modern
Hi!
> > > Why? What's so special about the name 'ttyS'?
> >
> > It's the name that users of Linux expect built-in serial ports to have.
>
> Not really. The norm under Linux is for non-8250 ports to use
> properly-registered device numbers and names. There's not many which are
> still broken in
Hi!
Why? What's so special about the name 'ttyS'?
It's the name that users of Linux expect built-in serial ports to have.
Not really. The norm under Linux is for non-8250 ports to use
properly-registered device numbers and names. There's not many which are
still broken in this
On Wed, Apr 04, 2007 at 07:15:32PM +0100, Russell King wrote:
> *However* you still run into the issue that you do not know how many
> serial ports you will need to register a tty driver with the tty layer.
> Solve that technical problem and the idea of having a single namespace
> for chosen
On Thu, Apr 05, 2007 at 04:05:31PM +1000, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > And you always will be. The amount of pain involved in implementing
> > this, just so that people can call their serial port 'ttyS0', is _far_
> > more than it's worth. It could be done, but it's a
David Woodhouse writes:
> And you always will be. The amount of pain involved in implementing
> this, just so that people can call their serial port 'ttyS0', is _far_
> more than it's worth. It could be done, but it's a completely pointless
> waste of time and effort.
Avoiding breaking
David Woodhouse writes:
And you always will be. The amount of pain involved in implementing
this, just so that people can call their serial port 'ttyS0', is _far_
more than it's worth. It could be done, but it's a completely pointless
waste of time and effort.
Avoiding breaking userspace is
On Thu, Apr 05, 2007 at 04:05:31PM +1000, Paul Mackerras wrote:
David Woodhouse writes:
And you always will be. The amount of pain involved in implementing
this, just so that people can call their serial port 'ttyS0', is _far_
more than it's worth. It could be done, but it's a completely
On Wed, Apr 04, 2007 at 07:15:32PM +0100, Russell King wrote:
*However* you still run into the issue that you do not know how many
serial ports you will need to register a tty driver with the tty layer.
Solve that technical problem and the idea of having a single namespace
for chosen serial
From: Russell King <[EMAIL PROTECTED]>
Date: Wed, 4 Apr 2007 10:00:16 +0100
> On Wed, Apr 04, 2007 at 01:43:30AM -0700, David Miller wrote:
> > Well the "bad hack" we use on sparc gives usable serial ports,
> > properly ordered and using /dev/ttyS0, with a proper matching
> > console selection.
>
On Wed, 2007-04-04 at 19:15 +0100, Russell King wrote:
> And the simple answer to this (oh I've been here before) is to leave
> the existing serial allocations well alone.
>
> Then, you allocate a new major number and device name for the dynamically
> assigned space and arrange for the serial
On Wed, Apr 04, 2007 at 01:41:53PM -0400, Theodore Tso wrote:
> On Wed, Apr 04, 2007 at 09:16:42AM -0700, H. Peter Anvin wrote:
> > One option would be to move the 8250-based serial ports, to, say,
> > /dev/ttyN* (for National Semiconductors -- the best I could come up
> > with) and redefine
On Tue, Apr 03, 2007 at 06:23:07PM -0700, David Lang wrote:
>
> people working with ~50 serial ports or ethernet ports aren't useing stock
> distros anyway.
??? For "big servers", Suse SLES and RedHat RHEL are the defacto choices,
with Ubuntu a rising star. It doesn't get much more stock than
On Wed, Apr 04, 2007 at 09:16:42AM -0700, H. Peter Anvin wrote:
> One option would be to move the 8250-based serial ports, to, say,
> /dev/ttyN* (for National Semiconductors -- the best I could come up
> with) and redefine /dev/ttyS* as a serial port multiplexer which maps in
> all the types,
On Wed, Apr 04, 2007 at 12:34:53PM -0400, David Woodhouse wrote:
> On Wed, 2007-04-04 at 11:22 -0500, Linas Vepstas wrote:
> > The biggest problem would seem to be that the assignment would
> > depend on the detection order; there don't seem to be unique
> > id's that would help udev consistently
On Wed, 2007-04-04 at 11:22 -0500, Linas Vepstas wrote:
> The biggest problem would seem to be that the assignment would
> depend on the detection order; there don't seem to be unique
> id's that would help udev consistently assign device names in
> consistent order.
Of course there are. The
Theodore Tso wrote:
The other thing I would probably do if I were to do it all over again
is allow serial devices to be named independent of /dev/ttySx
interface, these days probably using /sysfs, so that you could easily
query to figure out what serial controllers/cards were on the system,
and
On Tue, Apr 03, 2007 at 04:09:08PM -0700, Brad Boyer wrote:
> The issue is that the naming should be consistent. I
> shouldn't need to know what the hardware is to use what is fundamentally
> an abstraction of "serial port" as far as the user is concerned. On
> Solaris, I can say "/dev/term/a" and
> One option would be to move the 8250-based serial ports, to, say,
> /dev/ttyN* (for National Semiconductors -- the best I could come up
> with) and redefine /dev/ttyS* as a serial port multiplexer which maps in
> all the types, for the ones that really want dynamic mapping.
I think this
On Wed, Apr 04, 2007 at 08:21:54AM -0400, Theodore Tso wrote:
> So if we're going to do the "Worse is Better" thing, what I'd suggest
> doing is that someone simply submit a hack so that pmac_zilog can
> steal minor numbers and use /dev/ttyS0. I accepted the patch way back
> when I was serial
Geert Uytterhoeven wrote:
Oh, and I always thought PTYs were moved to free up more minors for our
zillions of serial ports...
No, PTYs were moved because 64 ptys were woefully inadequate. 256 ptys
were enough of a shortage for many users.
The use of 16-bit Minix device numbers was a
David Lang wrote:
On Wed, 4 Apr 2007, Alan Cox wrote:
You don't get machines with 64 ethernet ports on add-in cards. There
are
good reasons for the naming schemes in use.
I've seen machines offering up to 48, what's the magic number that
makes you
need to chagne nameing schemes?
Have
On Wed, Apr 04, 2007 at 07:55:30PM +1000, Paul Mackerras wrote:
> Russell King writes:
> > FACT: there is no way to know at any particular driver registration time
> > how many "generic" serial ports will be available - as required for the
> > chardev and tty layers.
>
> I think the thing that
On Wed, 2007-04-04 at 16:58 +1000, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > A GUI PPP dialer should be
> > listing the available serial ports in the system whatever their names
> > are.
>
> How do you propose they do that? Neither kppp nor gnome-ppp seem to
> be able to do that
On Wed, 4 Apr 2007, Geert Uytterhoeven wrote:
> > > I don't see why that 'should' be the case. Certainly it _isn't_ the case
> > > on most supported platforms -- we have separate device numbers, and
> > > names, for most types of ports. There's only one or two drivers which
> > > abuse ttySn for
On Wed, Apr 04, 2007 at 09:38:03AM +0100, Russell King wrote:
> I think your perception is more wrong than you could ever think.
> Montavista would absolutely love all serial ports to be under the
> ttyS* naming, especially on ARM where there is a wide variety of
> different possibilities - ttyAM,
On Wed, Apr 04, 2007 at 12:14:34PM +0100, Alan Cox wrote:
> > If you want hierarchy, create it:
> >
> > /sys/blah/serial/controllerX/portY
> >
> > and keeping them all under the ttyS? major keeps the simple
> > cases working sanely too.
>
> Currently yes you could do that, but that would break
> If you want hierarchy, create it:
>
> /sys/blah/serial/controllerX/portY
>
> and keeping them all under the ttyS? major keeps the simple
> cases working sanely too.
Currently yes you could do that, but that would break all the back
compatibility.
-
To unsubscribe from this list: send the line
Russell King writes:
> FACT: you can only have one struct console with one name.
That could be solved by having the struct console at the generic
serial driver level rather than in the individual port drivers.
> FACT: there is no way to know at any particular driver registration time
> how
On Wed, 4 Apr 2007, Russell King wrote:
> On Tue, Apr 03, 2007 at 04:09:08PM -0700, Brad Boyer wrote:
> > The availability of the specific chip in question is a red herring in
> > my opinion. I do understand that 8250 compatible chips are very common
> > and are the most likely serial chips to be
On Wed, Apr 04, 2007 at 01:43:30AM -0700, David Miller wrote:
> From: Russell King <[EMAIL PROTECTED]>
> Date: Wed, 4 Apr 2007 09:38:03 +0100
>
> > However, despite people pressing for it, there's yet to be a *sane*
> > *technical* *solution* to the problem. All I've seen so far is one
> > bad
On Tue, Apr 03, 2007 at 04:09:08PM -0700, Brad Boyer wrote:
> The availability of the specific chip in question is a red herring in
> my opinion. I do understand that 8250 compatible chips are very common
> and are the most likely serial chips to be used with Linux. However, I
> will point out
From: Russell King <[EMAIL PROTECTED]>
Date: Wed, 4 Apr 2007 09:38:03 +0100
> However, despite people pressing for it, there's yet to be a *sane*
> *technical* *solution* to the problem. All I've seen so far is one
> bad hack.
Well the "bad hack" we use on sparc gives usable serial ports,
From: Russell King <[EMAIL PROTECTED]>
Date: Wed, 4 Apr 2007 08:52:44 +0100
> On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote:
> > From: David Woodhouse <[EMAIL PROTECTED]>
> > Date: Wed, 04 Apr 2007 01:19:59 -0400
> >
> > > I don't see why that 'should' be the case. Certainly it
On Wed, Apr 04, 2007 at 01:12:08AM -0700, David Miller wrote:
> Your ARM example holds zero water because that platform has all kinds
> of weird devices so people there are used to all kinds of non-standard
> conventions and naming.
I think your perception is more wrong than you could ever think.
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Wed, 04 Apr 2007 02:03:54 -0400
> On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
> > It 'should' be the case because that is what is easiest for users and
> > makes most sense from a user's point of view.
>
> I really don't buy that
On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote:
> From: David Woodhouse <[EMAIL PROTECTED]>
> Date: Wed, 04 Apr 2007 01:19:59 -0400
>
> > I don't see why that 'should' be the case. Certainly it _isn't_ the case
> > on most supported platforms -- we have separate device numbers, and
On Tue, Apr 03, 2007 at 06:21:25PM -0700, David Miller wrote:
> From: Alan Cox <[EMAIL PROTECTED]>
> Date: Wed, 4 Apr 2007 02:19:24 +0100
>
> > > I totally agree with Paul, the onboard serial device should get
> > > ttyS0 regardless of what hardare is used to drive it.
> >
> > Thats between you
On Tue, 3 Apr 2007, David Miller wrote:
> From: David Woodhouse <[EMAIL PROTECTED]>
> Date: Wed, 04 Apr 2007 01:19:59 -0400
>
> > I don't see why that 'should' be the case. Certainly it _isn't_ the case
> > on most supported platforms -- we have separate device numbers, and
> > names, for most
On Tue, 3 Apr 2007, David Miller wrote:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Wed, 4 Apr 2007 09:14:20 +1000
>
> > David Woodhouse writes:
> >
> > > There are proper device numbers registered for pmac_zilog now. Use them.
> >
> > Sigh. I guess this is inevitable, but IMNSHO this
David Woodhouse writes:
> A GUI PPP dialer should be
> listing the available serial ports in the system whatever their names
> are.
How do you propose they do that? Neither kppp nor gnome-ppp seem to
be able to do that currently. Gnome-ppp offers just /dev/modem and
/dev/ttyS[0123]. Kppp
David Woodhouse writes:
> > It 'should' be the case because that is what is easiest for users and
> > makes most sense from a user's point of view.
>
> I really don't buy that argument. People cope perfectly well
> with /dev/ttySA0 on StrongARM, with /dev/ttySC0 on SH, etc. If it isn't
Those
On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > Why? What's so special about the name 'ttyS'?
>
> It's the name that users of Linux expect built-in serial ports to have.
Not really. The norm under Linux is for non-8250 ports to use
properly-registered
On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
David Woodhouse writes:
Why? What's so special about the name 'ttyS'?
It's the name that users of Linux expect built-in serial ports to have.
Not really. The norm under Linux is for non-8250 ports to use
properly-registered device
David Woodhouse writes:
It 'should' be the case because that is what is easiest for users and
makes most sense from a user's point of view.
I really don't buy that argument. People cope perfectly well
with /dev/ttySA0 on StrongARM, with /dev/ttySC0 on SH, etc. If it isn't
Those are
David Woodhouse writes:
A GUI PPP dialer should be
listing the available serial ports in the system whatever their names
are.
How do you propose they do that? Neither kppp nor gnome-ppp seem to
be able to do that currently. Gnome-ppp offers just /dev/modem and
/dev/ttyS[0123]. Kppp offers
On Tue, 3 Apr 2007, David Miller wrote:
From: Paul Mackerras [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 09:14:20 +1000
David Woodhouse writes:
There are proper device numbers registered for pmac_zilog now. Use them.
Sigh. I guess this is inevitable, but IMNSHO this exposes a
On Tue, 3 Apr 2007, David Miller wrote:
From: David Woodhouse [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 01:19:59 -0400
I don't see why that 'should' be the case. Certainly it _isn't_ the case
on most supported platforms -- we have separate device numbers, and
names, for most types of
On Tue, Apr 03, 2007 at 06:21:25PM -0700, David Miller wrote:
From: Alan Cox [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 02:19:24 +0100
I totally agree with Paul, the onboard serial device should get
ttyS0 regardless of what hardare is used to drive it.
Thats between you and udev.
On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote:
From: David Woodhouse [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 01:19:59 -0400
I don't see why that 'should' be the case. Certainly it _isn't_ the case
on most supported platforms -- we have separate device numbers, and
names,
From: David Woodhouse [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 02:03:54 -0400
On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
It 'should' be the case because that is what is easiest for users and
makes most sense from a user's point of view.
I really don't buy that argument.
I
On Wed, Apr 04, 2007 at 01:12:08AM -0700, David Miller wrote:
Your ARM example holds zero water because that platform has all kinds
of weird devices so people there are used to all kinds of non-standard
conventions and naming.
I think your perception is more wrong than you could ever think.
From: Russell King [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 08:52:44 +0100
On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote:
From: David Woodhouse [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 01:19:59 -0400
I don't see why that 'should' be the case. Certainly it _isn't_ the case
From: Russell King [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 09:38:03 +0100
However, despite people pressing for it, there's yet to be a *sane*
*technical* *solution* to the problem. All I've seen so far is one
bad hack.
Well the bad hack we use on sparc gives usable serial ports,
properly
On Tue, Apr 03, 2007 at 04:09:08PM -0700, Brad Boyer wrote:
The availability of the specific chip in question is a red herring in
my opinion. I do understand that 8250 compatible chips are very common
and are the most likely serial chips to be used with Linux. However, I
will point out that
On Wed, Apr 04, 2007 at 01:43:30AM -0700, David Miller wrote:
From: Russell King [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 09:38:03 +0100
However, despite people pressing for it, there's yet to be a *sane*
*technical* *solution* to the problem. All I've seen so far is one
bad hack.
On Wed, 4 Apr 2007, Russell King wrote:
On Tue, Apr 03, 2007 at 04:09:08PM -0700, Brad Boyer wrote:
The availability of the specific chip in question is a red herring in
my opinion. I do understand that 8250 compatible chips are very common
and are the most likely serial chips to be used
Russell King writes:
FACT: you can only have one struct console with one name.
That could be solved by having the struct console at the generic
serial driver level rather than in the individual port drivers.
FACT: there is no way to know at any particular driver registration time
how many
If you want hierarchy, create it:
/sys/blah/serial/controllerX/portY
and keeping them all under the ttyS? major keeps the simple
cases working sanely too.
Currently yes you could do that, but that would break all the back
compatibility.
-
To unsubscribe from this list: send the line
On Wed, Apr 04, 2007 at 12:14:34PM +0100, Alan Cox wrote:
If you want hierarchy, create it:
/sys/blah/serial/controllerX/portY
and keeping them all under the ttyS? major keeps the simple
cases working sanely too.
Currently yes you could do that, but that would break all the back
On Wed, Apr 04, 2007 at 09:38:03AM +0100, Russell King wrote:
I think your perception is more wrong than you could ever think.
Montavista would absolutely love all serial ports to be under the
ttyS* naming, especially on ARM where there is a wide variety of
different possibilities - ttyAM,
On Wed, 4 Apr 2007, Geert Uytterhoeven wrote:
I don't see why that 'should' be the case. Certainly it _isn't_ the case
on most supported platforms -- we have separate device numbers, and
names, for most types of ports. There's only one or two drivers which
abuse ttySn for anything
On Wed, 2007-04-04 at 16:58 +1000, Paul Mackerras wrote:
David Woodhouse writes:
A GUI PPP dialer should be
listing the available serial ports in the system whatever their names
are.
How do you propose they do that? Neither kppp nor gnome-ppp seem to
be able to do that currently.
On Wed, Apr 04, 2007 at 07:55:30PM +1000, Paul Mackerras wrote:
Russell King writes:
FACT: there is no way to know at any particular driver registration time
how many generic serial ports will be available - as required for the
chardev and tty layers.
I think the thing that davem and I
David Lang wrote:
On Wed, 4 Apr 2007, Alan Cox wrote:
You don't get machines with 64 ethernet ports on add-in cards. There
are
good reasons for the naming schemes in use.
I've seen machines offering up to 48, what's the magic number that
makes you
need to chagne nameing schemes?
Have
On Wed, Apr 04, 2007 at 08:21:54AM -0400, Theodore Tso wrote:
So if we're going to do the Worse is Better thing, what I'd suggest
doing is that someone simply submit a hack so that pmac_zilog can
steal minor numbers and use /dev/ttyS0. I accepted the patch way back
when I was serial
Geert Uytterhoeven wrote:
Oh, and I always thought PTYs were moved to free up more minors for our
zillions of serial ports...
No, PTYs were moved because 64 ptys were woefully inadequate. 256 ptys
were enough of a shortage for many users.
The use of 16-bit Minix device numbers was a
Theodore Tso wrote:
The other thing I would probably do if I were to do it all over again
is allow serial devices to be named independent of /dev/ttySx
interface, these days probably using /sysfs, so that you could easily
query to figure out what serial controllers/cards were on the system,
and
On Tue, Apr 03, 2007 at 04:09:08PM -0700, Brad Boyer wrote:
The issue is that the naming should be consistent. I
shouldn't need to know what the hardware is to use what is fundamentally
an abstraction of serial port as far as the user is concerned. On
Solaris, I can say /dev/term/a and know
One option would be to move the 8250-based serial ports, to, say,
/dev/ttyN* (for National Semiconductors -- the best I could come up
with) and redefine /dev/ttyS* as a serial port multiplexer which maps in
all the types, for the ones that really want dynamic mapping.
I think this makes it
On Wed, 2007-04-04 at 11:22 -0500, Linas Vepstas wrote:
The biggest problem would seem to be that the assignment would
depend on the detection order; there don't seem to be unique
id's that would help udev consistently assign device names in
consistent order.
Of course there are. The
On Wed, Apr 04, 2007 at 12:34:53PM -0400, David Woodhouse wrote:
On Wed, 2007-04-04 at 11:22 -0500, Linas Vepstas wrote:
The biggest problem would seem to be that the assignment would
depend on the detection order; there don't seem to be unique
id's that would help udev consistently assign
On Wed, Apr 04, 2007 at 09:16:42AM -0700, H. Peter Anvin wrote:
One option would be to move the 8250-based serial ports, to, say,
/dev/ttyN* (for National Semiconductors -- the best I could come up
with) and redefine /dev/ttyS* as a serial port multiplexer which maps in
all the types, for
On Tue, Apr 03, 2007 at 06:23:07PM -0700, David Lang wrote:
people working with ~50 serial ports or ethernet ports aren't useing stock
distros anyway.
??? For big servers, Suse SLES and RedHat RHEL are the defacto choices,
with Ubuntu a rising star. It doesn't get much more stock than
On Wed, Apr 04, 2007 at 01:41:53PM -0400, Theodore Tso wrote:
On Wed, Apr 04, 2007 at 09:16:42AM -0700, H. Peter Anvin wrote:
One option would be to move the 8250-based serial ports, to, say,
/dev/ttyN* (for National Semiconductors -- the best I could come up
with) and redefine /dev/ttyS*
On Wed, 2007-04-04 at 19:15 +0100, Russell King wrote:
And the simple answer to this (oh I've been here before) is to leave
the existing serial allocations well alone.
Then, you allocate a new major number and device name for the dynamically
assigned space and arrange for the serial layer to
From: Russell King [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 10:00:16 +0100
On Wed, Apr 04, 2007 at 01:43:30AM -0700, David Miller wrote:
Well the bad hack we use on sparc gives usable serial ports,
properly ordered and using /dev/ttyS0, with a proper matching
console selection.
Well yes,
David Woodhouse writes:
> Why? What's so special about the name 'ttyS'?
It's the name that users of Linux expect built-in serial ports to have.
> > The built-in ports can generally be enumerated early on boot in a
> > stable order, and they should be assigned the low ttySn numbers,
> >
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Wed, 04 Apr 2007 01:19:59 -0400
> I don't see why that 'should' be the case. Certainly it _isn't_ the case
> on most supported platforms -- we have separate device numbers, and
> names, for most types of ports. There's only one or two drivers which
On Wed, 2007-04-04 at 14:20 +1000, Paul Mackerras wrote:
> I never suggested *all* serial ports should be /dev/ttySn, I said that
> the built-in ports on the motherboard should be /dev/ttySn.
Why? What's so special about the name 'ttyS'?
> The built-in ports can generally be enumerated early
Alan Cox writes:
> That would be completely unmanagable on many systems with multiport
> controllers and interfaces where the naming tells you things like which
> cable port off which socket off which multiplexor is the one you are
> talking about.
I never suggested *all* serial ports should be
On Wed, 4 Apr 2007, Alan Cox wrote:
> You don't get machines with 64 ethernet ports on add-in cards. There are
> good reasons for the naming schemes in use.
If they made them I'd build one.
http://innerfire.net/pics/projects/21portfirewall_2.jpg
Gerhard
--
Gerhard Mack
[EMAIL
On Tue, 3 Apr 2007, [EMAIL PROTECTED] wrote:
On Tue, 03 Apr 2007 16:09:08 PDT, Brad Boyer said:
an abstraction of "serial port" as far as the user is concerned. On
Solaris, I can say "/dev/term/a" and know that I will get the first
serial port if it is available without needing to care if it
Once upon a time, Brad Boyer <[EMAIL PROTECTED]> said:
>The point is that people are used to having "ttyS0" mean the first
>onboard serial port.
My first serial port is a USB dongle and is ttyUSB0. If the argument is
that all serials should be ttyS[0-9]+, are you going to change USB
adapters as
On Tue, 03 Apr 2007 16:09:08 PDT, Brad Boyer said:
> an abstraction of "serial port" as far as the user is concerned. On
> Solaris, I can say "/dev/term/a" and know that I will get the first
> serial port if it is available without needing to care if it is the
> zs, se or asy driver talking to
1 - 100 of 168 matches
Mail list logo
