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 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 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 r
h port it's ip range and blocks 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
ress 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] Sto
> 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 VLAN-
> "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 p
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 t
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
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 comp
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
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 laye
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
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, fo
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 di
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 makes
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 main
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 major
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 you
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 d
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 curr
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 a
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 a
> 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 many
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 u
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 ha
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
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,
proper
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 _is
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 argume
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 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 typ
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 ex
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 offer
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
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 dev
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,
> > regardles
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 on
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 PROTECTED
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 i
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 the
On Tue, 3 Apr 2007, David Lang wrote:
so leave all the ports numbered 0-49, but let people who need to know run a
tool (even if it's dmesg -s 20 |grep ttyS) to learn the details of what
hardware is used to run what port.
and by the way, this is exactly what I do on machines with different
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 you tried working with 48
From: Alan Cox <[EMAIL PROTECTED]>
Date: Wed, 4 Apr 2007 02:44:00 +0100
> Well the better designed serial setups on Linux use numbering so that you
> can look on the multiplexor boxes and know straight away what the
> correlation between port number and name is. In the same was as "S0 is
> console
From: Alan Cox <[EMAIL PROTECTED]>
Date: Wed, 4 Apr 2007 02:36:37 +0100
> I've no fundamental problem with S0->console port 1, S1 -> console port 2
> etc, but the general notion that type and positional information doesn't
> matter is complete and utter bollocks when you try and apply it to any
>
From: David Lang <[EMAIL PROTECTED]>
Date: Tue, 3 Apr 2007 18:07:06 -0700 (PDT)
> I've seen machines offering up to 48, what's the magic number that makes you
> need to chagne nameing schemes?
Yep, excellent point.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
> > 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 you tried working with 48 ports when they are not n
On Wed, 4 Apr 2007, Alan Cox wrote:
I don't need to know anything about the inanrds of my computer to
bring up the ethernet interface, me caveman me bringup eth0, me on
network, caveman happy. The same should be true for serial ports.
You don't get machines with 64 ethernet ports on add-in ca
> 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 the define is TTY_MAJOR, not 8250_MAJOR. It seems
> to me that whoever named it was thinking in more generic terms.
The define goe
> Using different majors for different instances of the exact same kind
> of device is really not smart. It's a serial port, and if you try
> to dress it up to be something else you run into all kinds of problems.
Disagree. There are lots of good reasons you need to know which
port/which card/whi
On Tue, 2007-04-03 at 18:17 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Wed, 04 Apr 2007 11:13:12 +1000
>
> > It worked before the new serial core, we had a "tweak" in the old 8250
> > driver to be able to share minors, but that got busted when Russell
> >
> I don't need to know anything about the inanrds of my computer to
> bring up the ethernet interface, me caveman me bringup eth0, me on
> network, caveman happy. The same should be true for serial ports.
You don't get machines with 64 ethernet ports on add-in cards. There are
good reasons for th
> The TTY_MAJOR should have never belonged to 8250.c in the first place.
> I know it's just my opinion, but I think this major device should be
> owned by the serial core, and it shouldn't matter what chip drives each
> individual port. Each hardware driver should just register with the
> core how
On Tue, Apr 03, 2007 at 08:54:10PM -0400, David Woodhouse wrote:
> 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
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.
That might be true when udev exists, but it doesn't for the consol
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Wed, 04 Apr 2007 11:13:12 +1000
> It worked before the new serial core, we had a "tweak" in the old 8250
> driver to be able to share minors, but that got busted when Russell
> rewrote the whole thing. I remember asking him back when he still
> 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.
> Generalizing this minor number allocation for ttyS? might be the
> best way to handle this.
Again this is a udev issue. udev can certainly do a
On Tue, 2007-04-03 at 16:56 -0700, David Miller wrote:
> From: David Woodhouse <[EMAIL PROTECTED]>
> Date: Tue, 03 Apr 2007 19:28:36 -0400
>
> > Abusing the 8250 device numbers prevents the 8250 module from being
> > loaded at the same time as pmac_zilog, and means you can't have both
> > internal
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Tue, 03 Apr 2007 20:54:10 -0400
> 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 tha
On Tue, 2007-04-03 at 20:12 -0400, David Woodhouse wrote:
> On Tue, 2007-04-03 at 17:02 -0700, David Miller wrote:
> > Sparc does the same thing, it's a common convention and you really
> > should not break it.
>
> I thought that argument was lost many years ago. It _used_ to be a
> common convent
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 re
On Tue, Apr 03, 2007 at 07:28:36PM -0400, David Woodhouse wrote:
> I agree to a certain extent -- but then again, why should a user know or
> care about the name /dev/ttyS0 _either_? A GUI PPP dialer should be
> listing the available serial ports in the system whatever their names
> are.
The momen
On Tue, Apr 03, 2007 at 08:12:48PM -0400, David Woodhouse wrote:
> On Tue, 2007-04-03 at 17:02 -0700, David Miller wrote:
> > Sparc does the same thing, it's a common convention and you really
> > should not break it.
>
> I thought that argument was lost many years ago. It _used_ to be a
> common
On Tue, Apr 03, 2007 at 07:57:22PM -0400, David Woodhouse wrote:
> > The TTY_MAJOR should have never belonged to 8250.c in the first place.
> > I know it's just my opinion, but I think this major device should be
> > owned by the serial core, and it shouldn't matter what chip drives each
> > indivi
On Tue, 2007-04-03 at 17:02 -0700, David Miller wrote:
> Sparc does the same thing, it's a common convention and you really
> should not break it.
I thought that argument was lost many years ago. It _used_ to be a
common convention; we got better.
> Every powerpc and sparc system out that is usin
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Tue, 03 Apr 2007 19:57:22 -0400
> Not really. Non-8250 serial ports, such as the multiport PCI cards from
> Cyclades, Stallion, etc. have had their own device numbers for _years_.
> With hindsight, it was a mistake for pmac_zilog ever to have been ca
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Tue, 03 Apr 2007 19:28:36 -0400
> Abusing the 8250 device numbers prevents the 8250 module from being
> loaded at the same time as pmac_zilog, and means you can't have both
> internal port and PCMCIA or PCI 8250 ports active at the same time.
Dynami
On Tue, 2007-04-03 at 14:29 -0700, Brad Boyer wrote:
> On Tue, Apr 03, 2007 at 07:28:36PM -0400, David Woodhouse wrote:
> > I agree to a certain extent -- but then again, why should a user know or
> > care about the name /dev/ttyS0 _either_? A GUI PPP dialer should be
> > listing the available seri
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 weakness
> in our serial subsystem.
>
> The pro
On Wed, 2007-04-04 at 09:14 +1000, Paul Mackerras wrote:
> Sigh. I guess this is inevitable, but IMNSHO this exposes a weakness
> in our serial subsystem.
>
> The problem is that this means that a user has to know "oh, the serial
> port on my computer is implemented with a Z85C30 chip, therefore
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 weakness
in our serial subsystem.
The problem is that this means that a user has to know "oh, the serial
port on my computer is implemen
84 matches
Mail list logo
