[PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

There are proper device numbers registered for pmac_zilog now. Use them.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

diff --git a/drivers/serial/pmac_zilog.c b/drivers/serial/pmac_zilog.c
index 752ef07..579266d 100644
--- a/drivers/serial/pmac_zilog.c
+++ b/drivers/serial/pmac_zilog.c
@@ -99,9 +99,10 @@ static DEFINE_MUTEX(pmz_irq_mutex);
 
 static struct uart_driver pmz_uart_reg = {
 	.owner		=	THIS_MODULE,
-	.driver_name	=	"ttyS",
-	.dev_name	=	"ttyS",
-	.major		=	TTY_MAJOR,
+	.driver_name	=	"ttyPZ",
+	.dev_name	=	"ttyPZ",
+	.major		=	204,
+	.minor		=	192,
 };
 
 
@@ -1800,7 +1801,6 @@ static int __init pmz_register(void)
 	
 	pmz_uart_reg.nr = pmz_ports_count;
 	pmz_uart_reg.cons = PMACZILOG_CONSOLE;
-	pmz_uart_reg.minor = 64;
 
 	/*
 	 * Register this driver with the serial core

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Brad Boyer]

On Tue, Apr 03, 2007 at 10:25:45AM -0400, David Woodhouse wrote:
> There are proper device numbers registered for pmac_zilog now. Use them.
> 
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
> 
> diff --git a/drivers/serial/pmac_zilog.c b/drivers/serial/pmac_zilog.c
> index 752ef07..579266d 100644
> --- a/drivers/serial/pmac_zilog.c
> +++ b/drivers/serial/pmac_zilog.c
> @@ -99,9 +99,10 @@ static DEFINE_MUTEX(pmz_irq_mutex);
>  
>  static struct uart_driver pmz_uart_reg = {
>  	.owner		=	THIS_MODULE,
> -	.driver_name	=	"ttyS",
> -	.dev_name	=	"ttyS",
> -	.major		=	TTY_MAJOR,
> +	.driver_name	=	"ttyPZ",
> +	.dev_name	=	"ttyPZ",
> +	.major		=	204,
> +	.minor		=	192,
>  };
>  
>  
> @@ -1800,7 +1801,6 @@ static int __init pmz_register(void)
>  	
>  	pmz_uart_reg.nr = pmz_ports_count;
>  	pmz_uart_reg.cons = PMACZILOG_CONSOLE;
> -	pmz_uart_reg.minor = 64;
>  
>  	/*
>  	 * Register this driver with the serial core
> 

Shouldn't we have defines for these? It doesn't seem good to have more
magic numbers floating around in the code.

	Brad Boyer
	flar@allandria.com

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

On Tue, 2007-04-03 at 13:37 -0700, Brad Boyer wrote:
> Shouldn't we have defines for these? It doesn't seem good to have more
> magic numbers floating around in the code.

I wondered about that, but decided against it. They're only used in one
place, and it's obvious what they are and where they come from. It's not
as if '#define PMAC_ZILOG_MAJOR 204' and '.major = PMAC_ZILOG_MAJOR'
would actually make it any clearer. Quite the opposite, in fact, since
204 is used for other things too.

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Paul Mackerras]

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 implemented with a Z85C30 chip, therefore it's
/dev/ttyPZ0 not /dev/ttyS0, like it would be if the designers had used
a 16C550".

Plus I'm sure this is going to mean that people using gui ppp dialers
on powermacs will suddenly find that the gui can no longer find their
serial port and they have no idea why.

Why should a user know or care about that?  It really should be "it's
the built-in serial port on my computer therefore it's /dev/ttyS0".

Paul.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

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 it's
> /dev/ttyPZ0 not /dev/ttyS0, like it would be if the designers had used
> a 16C550".
> 
> Plus I'm sure this is going to mean that people using gui ppp dialers
> on powermacs will suddenly find that the gui can no longer find their
> serial port and they have no idea why.

> Why should a user know or care about that?  It really should be "it's
> the built-in serial port on my computer therefore it's /dev/ttyS0".

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.

And nobody _forces_ you to use the name ttyPZ0. If you really want, you
can call it ttyS0.... just mknod /dev/ttyS0 204 192

You could even have udev rules which share the /dev/ttyS$N namespace
between _all_ kinds of serial ports, if you really want to.

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.
 
-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Brad Boyer]

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 moment you do serial console, the user needs to know. I would hate
having to have console=ttyPZ0 in my kernel command line. Does that even
work? I didn't see a change to the console setup in your patch. Serial
is for much more than modems and PDA sync. In fact, I would think that
many more Linux systems these days use serial for console than for any
other purpose due to the use of such setups in large data centers and
the reduction in serial peripherals for desktop computers.

> And nobody _forces_ you to use the name ttyPZ0. If you really want, you
> can call it ttyS0.... just mknod /dev/ttyS0 204 192
> 
> You could even have udev rules which share the /dev/ttyS$N namespace
> between _all_ kinds of serial ports, if you really want to.
> 
> 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.

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 many ports it has and should be allocated from the same range.

This situation is purely a side-effect of the fact that all the
original Linux supported hardware used the 8250 driver and everyone
who didn't use 8250 was marginalized enough that they got ignored.

	Brad Boyer
	flar@allandria.com

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

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 serial ports in the system whatever their names
> > are.
> 
> The moment you do serial console, the user needs to know. I would hate
> having to have console=ttyPZ0 in my kernel command line. Does that even
> work? I didn't see a change to the console setup in your patch.

Oops. Well-spotted; I forgot to change that. I'll send a replacement
patch.

> 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 many ports it has and should be allocated from the same range.

Yeah, because that works out really well for Ethernet devices and SCSI
disks, with different numbers every day of the week according to what
order we happen to load drivers in. :)

> This situation is purely a side-effect of the fact that all the
> original Linux supported hardware used the 8250 driver and everyone
> who didn't use 8250 was marginalized enough that they got ignored.

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 called
'ttyS0' and to have used the ttyS0 device numbers in the first place.

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Brad Boyer]

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
> > individual port. Each hardware driver should just register with the
> > core how many ports it has and should be allocated from the same range.
> 
> Yeah, because that works out really well for Ethernet devices and SCSI
> disks, with different numbers every day of the week according to what
> order we happen to load drivers in. :)

It just leads to the problem ethernet has on BSD/Solaris/etc. You have
to ask yourself "is the ethernet on this system le0 or hme0 or maybe
something else entirely?" in this case. I agree it does solve the issue
of detection order breaking the configuration, but it is less than ideal.
I think the issue of the devices shuffling around is less likely to be
a problem on serial, although we don't have the nice uniqueness of
hardware identifiers that was used to do device renaming in ethernet.

I suppose my opinion on this shows that I didn't come from the x86
side of Linux. 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. I know it was that way when m68k tried to merge
in their serial framework that did allow such sharing across any
number of hardware drivers.

	Brad Boyer
	flar@allandria.com

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

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

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Brad Boyer]

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 around that.

I never claimed there was anything magical about those particular values
and I don't intend to do that in the future. The issue is one of
standardization. As an example, Solaris does use the same device names
for both Zilog 8530 and 8250 ports in spite of naming ethernet devices
based on the hardware type. I just checked the man pages on a Solaris 9
system to be sure. 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 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 hardware.

Note that I'm not suggesting we should do what Solaris does because
Sun decided it was the way to do it. I'm just pointing out an example.

> 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.

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 the define is TTY_MAJOR, not 8250_MAJOR. It seems
to me that whoever named it was thinking in more generic terms.

> 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?

The point is that people are used to having "ttyS0" mean the first
onboard serial port. I firmly believe that the user-space programs
should need to know as little as possible about the hardware, and it
would be nice to abstract that away from the end user as well. We've
moved toward commonality and standarization in other areas, and I
think we should here as well.

	Brad Boyer
	flar@allandria.com

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Alan Cox]

> 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 goes back the very first days of Linux. I doubt whoever named
it (Linus I imagine) had even considered that anyone else might be
running his terminal emulator at that point.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

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 hardware.

This is fine if you're trying to boot and find your system console.

It blows complete chunks if the port you're trying to find is the
first port on the special serial card that supports speeds above 115kbaud
because we have a real-time constraint, and even at 115k you fall short
on the timing budget (actual real-life issue we hit on an SGI running IRIX
a number of years ago. Blowing the budget often resulted in a 3,000 pound
motion base to turn into a 3,000 pound jackhammer:

http://www.sv.vt.edu/future/cave/resprj/crane/crane_thor/2001FebReport.html
http://www.moog.com/Media/1/6D2000E500-395_1102.pdf

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Lang]

On Tue, 3 Apr 2007, Valdis.Kletnieks@vt.edu 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 is the
>> zs, se or asy driver talking to the hardware.
>
> This is fine if you're trying to boot and find your system console.
>
> It blows complete chunks if the port you're trying to find is the
> first port on the special serial card that supports speeds above 115kbaud
> because we have a real-time constraint, and even at 115k you fall short
> on the timing budget (actual real-life issue we hit on an SGI running IRIX
> a number of years ago. Blowing the budget often resulted in a 3,000 pound
> motion base to turn into a 3,000 pound jackhammer:
> http://www.sv.vt.edu/future/cave/resprj/crane/crane_thor/2001FebReport.html
> http://www.moog.com/Media/1/6D2000E500-395_1102.pdf
>

but when you are looking for this port, you would lookup which port it is, make 
something active on that port (if only a getty), and then confirm the port by 
plugging into it and testing it.

in other words, if you have a special constraint you will have to pay attention 
to the hardware to make sure it meets those requriements.

this is no different then the fact that many motherboards contain a 100Mb 
ethernet port as well as a pair of 1Gb ethernet ports. if you need speeds above 
100Mb you better make sure your useing the right port, but we don't name network 
ports based on the type of card.

David Lang

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Russell King]

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 the define is TTY_MAJOR, not 8250_MAJOR. It seems
> to me that whoever named it was thinking in more generic terms.

You're reading too much into the name.  It's historical, and the reason
can still be seen in LANANA:

  4 char        TTY devices
                  0 = /dev/tty0         Current virtual console

                  1 = /dev/tty1         First virtual console
                    ...
                 63 = /dev/tty63        63rd virtual console
                 64 = /dev/ttyS0        First UART serial port
                    ...
                255 = /dev/ttyS191      192nd UART serial port

                UART serial ports refer to 8250/16450/16550 series devices.

When the drivers/char/serial.c driver was written, it was in the very
early days of Linux.  I'd guess that the major/minor numbers were similar
to Minix, thereby allowing a minixfs to be used as the initial filesystem
type.

Anyway, as you can see, defining chardev major 4 to be "8250_MAJOR" would
also be a misnomer because it's used for the virtual consoles, and it's
_that_ use for which it (probably) was called TTY_MAJOR.

(Note that in the very early days, this major also got used for PTY
devices.  Since then they've moved to major 2/3 and then we got Unix98
PTY support.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Geert Uytterhoeven]

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 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.
> 
> You're reading too much into the name.  It's historical, and the reason
> can still be seen in LANANA:
> 
>   4 char        TTY devices
>                   0 = /dev/tty0         Current virtual console
> 
>                   1 = /dev/tty1         First virtual console
>                     ...
>                  63 = /dev/tty63        63rd virtual console
>                  64 = /dev/ttyS0        First UART serial port
>                     ...
>                 255 = /dev/ttyS191      192nd UART serial port
> 
>                 UART serial ports refer to 8250/16450/16550 series devices.
> 
> When the drivers/char/serial.c driver was written, it was in the very
> early days of Linux.  I'd guess that the major/minor numbers were similar
> to Minix, thereby allowing a minixfs to be used as the initial filesystem
> type.
> 
> Anyway, as you can see, defining chardev major 4 to be "8250_MAJOR" would
> also be a misnomer because it's used for the virtual consoles, and it's
> _that_ use for which it (probably) was called TTY_MAJOR.
> 
> (Note that in the very early days, this major also got used for PTY
> devices.  Since then they've moved to major 2/3 and then we got Unix98
> PTY support.)

Oh, and I always thought PTYs were moved to free up more minors for our
zillions of serial ports...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[H. Peter Anvin]

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 headache in Linux for 
many, many years.  We didn't get past that one until the 2.6 kernel series.

	-hpa

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Linas Vepstas]

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 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 hardware.

I presume that a correctly structured set of rules for udev should
accomplish the same thing; when udev runs, it could create links to
/dev/serial0 or /dev/serial/0 etc. as you wish. Applications
"should" use the udev-created links, not the raw, underlying device
nodes.

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.

--linas

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

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 different types of ports have different device
numbers. As long as we don't do anything silly like putting all the
serial drivers on the same major number, we can tell them apart
relatively well.

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Linas Vepstas]

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 device names in 
> > consistent order. 
> 
> Of course there are. The different types of ports have different device
> numbers. As long as we don't do anything silly like putting all the
> serial drivers on the same major number, we can tell them apart
> relatively well.

Sure, but if two different pci serial cards are moved around  
to different pci slots, they'll be detected in a different order. 
Similarly if one has some usb-to-serial converter that might get
plugged in after boot, or maybe some serial port that shows up
only when a laptop is docked into a docking station.

--linas

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: David Woodhouse <dwmw2@infradead.org>
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 that
> SPARC has and try to move it to generic code. But what's the point?

The point is that it will work and the user will not be bothered
with what kind of serial port they happen to have.  A major number
per serial chip type is incredibly stupid.

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.

It's a serial port dammit, don't make it something else!

In the case of multiple instances, ordering is a sperate issue from
naming.  You keep bringing up the ordering issue but it distracts away
from the more important part which is the user having to know what
kind of serial port they have.

It's a serial port, and like a scsi disk or and ethernet interface, we
should give it a consistent name.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Alan Cox]

> 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 the naming schemes in use.

Alan

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Lang]

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 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?

I also know of systems with 50 serial ports on them. the fact that some of the 
serial ports on the front panel were named differently then other serial ports 
on the front panel sure didn't make my life easier in dealing with them.

David Lang

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Alan Cox]

> > 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 numbered 0-47 or
in some logical fashion ?

> I also know of systems with 50 serial ports on them. the fact that some of the 
> serial ports on the front panel were named differently then other serial ports 
> on the front panel sure didn't make my life easier in dealing with them.

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 1" is nice to have its also nice to have "mux 1 port 4" easily
calculable not think

	"Well now we've got 2 console ports thats S0/S1, a 4 port PCI
card found before us so thats S2 to S5, so we must start as S6 to mux 1
port 4 is going to be umm .. S10"

Let alone the hell that breaks out when you add a new card using this
system.

The ethernet one works better because you've usually got a MAC address
per port (although its not required by any means), which means that the
scripts in the distro can do naming persistency for you and hide the
whole exciting game from you.

Which is also another reason for building the "all serial devices"
mapping by using udev, as it can provide multiple simultaneous views. The
serial console unfortunately rather breaks that approach as Dave pointed
out

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Lang]

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 ports when they are not numbered 0-47 or
> in some logical fashion ?

no, but that's what we're wanting with serial ports as well. a system with 50 
serial ports should have them numbered 0-49, not typea0-5, typeb0-39, typec0-5

>> I also know of systems with 50 serial ports on them. the fact that some of the
>> serial ports on the front panel were named differently then other serial ports
>> on the front panel sure didn't make my life easier in dealing with them.
>
> 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 1" is nice to have its also nice to have "mux 1 port 4" easily
> calculable not think
>
> 	"Well now we've got 2 console ports thats S0/S1, a 4 port PCI
> card found before us so thats S2 to S5, so we must start as S6 to mux 1
> port 4 is going to be umm .. S10"
>
> Let alone the hell that breaks out when you add a new card using this
> system.
>
> The ethernet one works better because you've usually got a MAC address
> per port (although its not required by any means), which means that the
> scripts in the distro can do naming persistency for you and hide the
> whole exciting game from you.

people working with ~50 serial ports or ethernet ports aren't useing stock 
distros anyway.

> Which is also another reason for building the "all serial devices"
> mapping by using udev, as it can provide multiple simultaneous views. The
> serial console unfortunately rather breaks that approach as Dave pointed
> out

I would reverse this. instead of having a bunch of different names and then 
requiring a tool to create sane names from them, start off with a nice nameing 
scheme and have a tool that tells you the under-the-covers details.

so leave all the ports numbered 0-49, but let people who need to know run a 
tool (even if it's dmesg -s 200000 |grep ttyS) to learn the details of what 
hardware is used to run what port.

for 99.99% of the users they will never need to use this tool (things will just 
work becouse they only have one type, or someone else put lables on the box 
before shipping it to you), and in the other 0.01% of the users, they are 
running a tool anyway to get the gory details of things so it isn't a big 
harship for them.

David Lang

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Lang]

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 200000 |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 types of 
ethernet cards to figure out what ethX name the different types of cards get. 
after I've figured that out I learn which order the cards of that type are by 
plugging things into a port to see what shows up (knowing the MAC address 
doesn't do you any good if you don't know what hole to plug the wire into)

and yes, the nameing does get messed up when you plugin a new card, or enable a 
driver that you didn't have before, but as painful as that is it's pain that 
only I have to deal with when reconfiguring the hardware, all the other 
sysadmins who use the systems just know what port is what, they don't need to 
know that box A has tulip based quad cards while box B has starfire based quad 
cards, they just know 'eth0 is the one labled 0, eth18 is the one labled 18'

keep it simple for as many people as possible, don't spread the pain. those who 
will feel the pain are already dealing with it and the change to hardware-based 
named doesn't help them anyway.

David Lang

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[H. Peter Anvin]

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 tried working with 48 ports when they are not numbered 0-47 or
>> in some logical fashion ?
> 
> no, but that's what we're wanting with serial ports as well. a system 
> with 50 serial ports should have them numbered 0-49, not typea0-5, 
> typeb0-39, typec0-5
> 

I would actually disagree.  I have systems with multiport serial cards 
installed, and I much prefer those to be named differently.  Not only do 
I not have to worry about the same problem I *constantly* have with 
onboard Ethernet cards -- whoops I just installed an expansion card and 
suddenly my onboard NIC is eth2! -- but the expansion serial ports tend 
to be *different.*

For example, on my serial server, the Cyclades ports (ttyC*) use RJ-45 
connections from an external expansion module, whereas of course the 
builtin ones (ttyS*) use DB-9s.

	-hpa

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Linas Vepstas]

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 that.

> > Which is also another reason for building the "all serial devices"
> > mapping by using udev, as it can provide multiple simultaneous views. The
> > serial console unfortunately rather breaks that approach as Dave pointed
> > out
> 
> I would reverse this. instead of having a bunch of different names and then 
> requiring a tool to create sane names from them, start off with a nice nameing 
> scheme and have a tool that tells you the under-the-covers details.

Except that udev already exists, and is widely deployed by most distros
to handle the "sane naming" problem. In particular, "sane naming"
becomes hard if devices can be hotplugged, whether they are usb or pci
(e.g. a usb-to-serial converter).

--linas

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
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 1" is nice to have its also nice to have "mux 1 port 4" easily
> calculable not think

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.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Alan Cox]

> 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.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Olivier Galibert]

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
> compatibility.

libata's hd->s* does that too, with probably a much larger impact.
Could udev be useful for once and make back compatibility symlinks?
Unifying serial the same way disks, cdroms, network, etc got unified
has some charm.

  OG.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: David Lang <david.lang@digitalinsight.com>
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.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Gerhard Mack]

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

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Benny Amorsen]

>>>>> "GM" == Gerhard Mack <gmack@innerfire.net> 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 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).


/Benny

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Roland Dreier]

 > 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-capable switches with 10gig
and 1gig ports to fan out each 10gig link from your server to 10 1-gig
ports.  That would get you 40 ports of 1-gig from each server (plus
whatever the server has on board).

 - R.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Gerhard Mack]

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.

http://innerfire.net/pics/projects/21portfirewall_2.jpg
(assigns each 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 <rdreier@cisco.com>
> To: Benny Amorsen <benny+usenet@amorsen.dk>
> Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
> 
>  > 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-capable switches with 10gig
> and 1gig ports to fan out each 10gig link from your server to 10 1-gig
> ports.  That would get you 40 ports of 1-gig from each server (plus
> whatever the server has on board).
> 
>  - R.
> -
> 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/
> 

--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Lang]

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, dual core cpu, 2G ram 2xgigE on the 
motherboard (1x100M on motherboard), 4x Intel E1000 quad port cards, 120G SATA 
drive, DVD burner, floppy

3u, 18 gig ports, just under $5k

if you have 36" deep racks you can put them back to back and have two of these 
in 3u (12 gig ports per u)

not nessasarily the cheapest available, but they've been reliable, and there's 
pleanty of CPU and ram to handle firewall tasks.

besides, sometimes you don't want to trust the closed-source vlan 
implementations on the switches ;-)

David Lang

> http://innerfire.net/pics/projects/21portfirewall_2.jpg
> (assigns each 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 <rdreier@cisco.com>
>> To: Benny Amorsen <benny+usenet@amorsen.dk>
>> Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
>>
>> > 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-capable switches with 10gig
>> and 1gig ports to fan out each 10gig link from your server to 10 1-gig
>> ports.  That would get you 40 ports of 1-gig from each server (plus
>> whatever the server has on board).
>>
>>  - R.
>> -
>> 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/
>>
>
> --
> Gerhard Mack
>
> gmack@innerfire.net
>
> <>< As a computer I find your faith in technology amusing.
> -
> 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/
>

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Geert Uytterhoeven]

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, dual core cpu, 2G ram 2xgigE on the 
> motherboard (1x100M on motherboard), 4x Intel E1000 quad port cards, 120G SATA 
> drive, DVD burner, floppy
> 
> 3u, 18 gig ports, just under $5k

I don't think we're still talking about _serial_ ports?

Gr{oetje,eeting}s,

						Geert

P.S. Yes, Ethernet is serial ;-)
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: David Woodhouse <dwmw2@infradead.org>
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 called
> 'ttyS0' and to have used the ttyS0 device numbers in the first place.

Sparc does the same thing, it's a common convention and you really
should not break it.

Every powerpc and sparc system out that is using ttyS0 with dynamic
minor numbers being allocated.  I really think this should be
generalized instead of breaking serial on every powerpc machine out
there.  (sparc won't be broken because we have our own copy of
the 8250 driver that does ttyS? minor allocations and keyboard/
mouse serio hookups properly).

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

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 using ttyS0 with dynamic
> minor numbers being allocated.  I really think this should be
> generalized instead of breaking serial on every powerpc machine out
> there.

Nobody's breaking anything. The patch _fixes_ serial, and allows powerpc
machines to use both z8530 and 8250 ports at the same time; something
which has been broken for a long time.

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Brad Boyer]

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 convention; we got better.

This argument was made and lost as you say. The problem is that the
resolution was a decision from on high. For the most part, everyone
kept their original opinion and nothing was truly resolved. I think
there was some resentment on the part of the losing side because
they felt their opinions weren't seriously considered. Please
correct me if my impressions of that were wrong. I was not directly
involved in such arguments at the time.

	Brad Boyer
	flar@allandria.com

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Benjamin Herrenschmidt]

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 convention; we got better.
> 
> > Every powerpc and sparc system out that is using ttyS0 with dynamic
> > minor numbers being allocated.  I really think this should be
> > generalized instead of breaking serial on every powerpc machine out
> > there.
> 
> Nobody's breaking anything. The patch _fixes_ serial, and allows powerpc
> machines to use both z8530 and 8250 ports at the same time; something
> which has been broken for a long time.

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 was
the serial maintainer, and he refused to bring back some sharing of
minors.

Ben.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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 was
> the serial maintainer, and he refused to bring back some sharing of
> minors.

Fork the 8250 driver like I did on Sparc so you can get the
dynamic minor behavior back :-))))

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Benjamin Herrenschmidt]

On Tue, 2007-04-03 at 18:17 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> 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 was
> > the serial maintainer, and he refused to bring back some sharing of
> > minors.
> 
> Fork the 8250 driver like I did on Sparc so you can get the
> dynamic minor behavior back :-))))

heh, maybe I can use your forked/sparc version :-)

Ben.

[PATCH v2] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

There are proper device numbers registered for pmac_zilog now. Use them,
and change the name of the device to 'ttyPZ%d'. This allows the
pmac_zilog and 8250 drivers to co-exist in the kernel.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

diff --git a/drivers/serial/pmac_zilog.c b/drivers/serial/pmac_zilog.c
index 752ef07..2ab23af 100644
--- a/drivers/serial/pmac_zilog.c
+++ b/drivers/serial/pmac_zilog.c
@@ -99,9 +99,10 @@ static DEFINE_MUTEX(pmz_irq_mutex);
 
 static struct uart_driver pmz_uart_reg = {
 	.owner		=	THIS_MODULE,
-	.driver_name	=	"ttyS",
-	.dev_name	=	"ttyS",
-	.major		=	TTY_MAJOR,
+	.driver_name	=	"ttyPZ",
+	.dev_name	=	"ttyPZ",
+	.major		=	204,
+	.minor		=	192,
 };
 
 
@@ -1776,7 +1777,7 @@ static void pmz_console_write(struct console *con, const char *s, unsigned int c
 static int __init pmz_console_setup(struct console *co, char *options);
 
 static struct console pmz_console = {
-	.name	=	"ttyS",
+	.name	=	"ttyPZ",
 	.write	=	pmz_console_write,
 	.device	=	uart_console_device,
 	.setup	=	pmz_console_setup,
@@ -1800,7 +1801,6 @@ static int __init pmz_register(void)
 	
 	pmz_uart_reg.nr = pmz_ports_count;
 	pmz_uart_reg.cons = PMACZILOG_CONSOLE;
-	pmz_uart_reg.minor = 64;
 
 	/*
 	 * Register this driver with the serial core

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Alan Cox]

> 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 many ports it has and should be allocated from the same range.

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.

You can't dynamically identify serial ports, you can't generally speaking
probe the device the other end and get persistant identifiers.

> This situation is purely a side-effect of the fact that all the
> original Linux supported hardware used the 8250 driver and everyone
> who didn't use 8250 was marginalized enough that they got ignored.

Nope. The original design used different numbers of each type of port
quite intentionally. Having handy names for the onboard ports is useful
as well but not related. One or two people cheated and its finally come
back to haunt them.

Alan

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Paul Mackerras]

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 /dev/ttySn, I said that
the built-in ports on the motherboard should be /dev/ttySn.  The
built-in ports can generally be enumerated early on boot in a stable
order, and they should be assigned the low ttySn numbers, regardless
of what chip is used to implement them.

Paul.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

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 boot in a
> stable order, and they should be assigned the low ttySn numbers,
> regardless of what chip is used to implement them. 

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 other than 8250 ports.

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: David Woodhouse <dwmw2@infradead.org>
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
> abuse ttySn for anything other than 8250 ports.

sunsu, sunzilog, pmac_zilog, sunsab, etc.

The list is longer than you think.  In fact the convention is
very well established.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Geert Uytterhoeven]

On Tue, 3 Apr 2007, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> 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
> > abuse ttySn for anything other than 8250 ports.
> 
> sunsu, sunzilog, pmac_zilog, sunsab, etc.

amiserial.

> The list is longer than you think.  In fact the convention is
> very well established.

And I guess the recently revived Atari serial driver, too.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Maciej W. Rozycki]

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 other than 8250 ports.
> > 
> > sunsu, sunzilog, pmac_zilog, sunsab, etc.
> 
> amiserial.
> 
> > The list is longer than you think.  In fact the convention is
> > very well established.
> 
> And I guess the recently revived Atari serial driver, too.

 And also DEC hardware, i.e. zs (which drives Zilog ports too) and dz 
(which handles integrated to the various extent clones of the original 
PDP-11 serial multiplexer ;-) ).

  Maciej

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Russell King]

On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> 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
> > abuse ttySn for anything other than 8250 ports.
> 
> sunsu, sunzilog, pmac_zilog, sunsab, etc.
> 
> The list is longer than you think.  In fact the convention is
> very well established.

... and has never ever worked along side the existing 8250 (or serial)
driver - therefore it can also be viewed as a long standing BUG.

We're really in this mess because it was decided that 8250 was going
to be called "serial", thereby causing everyone to believe that they
should be using the allocations for that driver. ;(

Had the allocation been called "PC 8250-based serial" in LANANA and
elsewhere, it probably wouldn't have been re-used.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: Russell King <rmk+lkml@arm.linux.org.uk>
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 <dwmw2@infradead.org>
> > 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
> > > abuse ttySn for anything other than 8250 ports.
> > 
> > sunsu, sunzilog, pmac_zilog, sunsab, etc.
> > 
> > The list is longer than you think.  In fact the convention is
> > very well established.
> 
> ... and has never ever worked along side the existing 8250 (or serial)
> driver - therefore it can also be viewed as a long standing BUG.

I forked the 8250 driver for Sparc, that's what sunsu is, and it works
along side sunzilog and sunsab, which also use the ttyS0 major, just
fine.

They also setup the console correctly, and even make sure it matches
what the user selected in the firmware environment variables.

It can be made to work.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Paul Mackerras]

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,
> > regardless of what chip is used to implement them. 
> 
> 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 other than 8250 ports.

It 'should' be the case because that is what is easiest for users and
makes most sense from a user's point of view.

You still haven't given any reason why a user should have to know or
care whether the built-in serial ports on his/her computer are
implemented with a 16C550 chip or a Z85C30 chip or something else.

Now, *maybe* the naming can be fixed up with udev.  I haven't invested
the week of my life that it would take to investigate the twisty maze
of shell scripts that udev seems to involve.

In any case your patch is a user-visible incompatible API change and
will break existing working setups, so it should only be put in after
suitable warning has been given.  Maybe we need a module parameter to
select between the old and new behaviour to ease the transition.

Paul.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

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 numbers and names. There's not many which are
still broken in this respect -- it's basically pmac_zilog and some Sun
UARTs, isn't it?

And even if it _were_ true, it wouldn't be a particularly good reason
for changing the way we handle serial ports under Linux.

> > > The built-in ports can generally be enumerated early on boot in a
> > > stable order, and they should be assigned the low ttySn numbers,
> > > regardless of what chip is used to implement them. 
> > 
> > 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 other than 8250 ports.
>
> 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
an 8250, it doesn't usually get called ttyS0. There's certainly nothing
_easier_ about ttyS0. Unless it's really an effort to type that extra
character :)

> You still haven't given any reason why a user should have to know or
> care whether the built-in serial ports on his/her computer are
> implemented with a 16C550 chip or a Z85C30 chip or something else.

Because that's the way serial ports are named under Linux. If you want
to change that, then take it up with the serial maintainer -- but
pmac_zilog as it is upstream at the moment is just _broken_. The module
just doesn't load if you have 8250 built in or loaded. That's what you
get when you abuse device numbers belonging to another driver.

> In any case your patch is a user-visible incompatible API change and
> will break existing working setups, so it should only be put in after
> suitable warning has been given.  Maybe we need a module parameter to
> select between the old and new behaviour to ease the transition.

Perhaps that's true; I'd certainly never seen a working setup with
pmac_zilog, because I'd never actually seen the module load. It's always
failed for me, because I have 8250 support built in to my kernels.

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Paul Mackerras]

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 embedded platforms and therefore don't have users who aren't
developers interacting with it as a general-purpose computer.

> an 8250, it doesn't usually get called ttyS0. There's certainly nothing
> _easier_ about ttyS0. Unless it's really an effort to type that extra
> character :)
> 
> > You still haven't given any reason why a user should have to know or
> > care whether the built-in serial ports on his/her computer are
> > implemented with a 16C550 chip or a Z85C30 chip or something else.
> 
> Because that's the way serial ports are named under Linux.

In other words we're too lame to abstract the hardware properly and
users just have to deal with it...

> > In any case your patch is a user-visible incompatible API change and
> > will break existing working setups, so it should only be put in after
> > suitable warning has been given.  Maybe we need a module parameter to
> > select between the old and new behaviour to ease the transition.
> 
> Perhaps that's true; I'd certainly never seen a working setup with
> pmac_zilog, because I'd never actually seen the module load. It's always
> failed for me, because I have 8250 support built in to my kernels.

You probably don't have a powermac or powerbook that has usable,
externally accessible serial ports either.  Plenty of other people do.

It seems Debian has both 8250 and pmac_zilog built in; not sure which
one wins.  Ubuntu has them both as modules and managed to get the
right one (pmac_zilog) loaded on a colleague's powerbook.  You'd know
better than me what FC does.

In any case there definitely are people using pmac_zilog successfully
on powermacs and we need to come up with a way to avoid breaking their
setups.  I'm prepared to accept that the Linux way is to be lame about
serial port naming provided that we avoid breaking existing working
setups.

Paul.

[PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[David Woodhouse]

On Wed, 2007-04-04 at 16:31 +1000, Paul Mackerras wrote:
> It seems Debian has both 8250 and pmac_zilog built in; not sure which
> one wins.  Ubuntu has them both as modules and managed to get the
> right one (pmac_zilog) loaded on a colleague's powerbook. 

So if you insert a PCMCIA card with an 8250-compatible port in it --
like a Bluetooth card or modem -- you won't get it to work, right? 

>  You'd know better than me what FC does.

Fedora has 8250 built in, which means pmac_zilog can never get loaded.

> In any case there definitely are people using pmac_zilog successfully
> on powermacs and we need to come up with a way to avoid breaking their
> setups.  I'm prepared to accept that the Linux way is to be lame about
> serial port naming provided that we avoid breaking existing working
> setups. 

OK, how about a config option to preserve the old behaviour...

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index ad9f321..09b2dd4 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -753,6 +753,25 @@ config SERIAL_PMACZILOG
 	  PowerMac machines.
 	  Say Y or M if you want to be able to these serial ports.
 
+config SERIAL_PMACZILOG_TTYS
+	bool "Use ttySn device nodes for Zilog z85c30"
+	depends on SERIAL_PMACZILOG
+	help
+	  The z85C30 driver historically used the device nodes which 
+	  are registed to the 8250 serial port driver, which led to the
+	  two drivers being unable to coexist; you could not use both
+	  z85C30 and 8250 type ports at the same time.
+
+	  The z83C30 driver was fixed to prevent this abuse by default,
+	  but this configuration option remains in order to allow backward
+	  compatibility by reverting to the old misbehaviour.
+
+	  If you enable this option, any z85c30 ports in the system will
+	  be registered as ttyS0 onwards, and you will be unable to use
+	  the 8250 module for PCMCIA or other standard UARTs.
+
+	  Say N.
+
 config SERIAL_PMACZILOG_CONSOLE
 	bool "Console on PowerMac z85c30 serial port"
 	depends on SERIAL_PMACZILOG=y
diff --git a/drivers/serial/pmac_zilog.c b/drivers/serial/pmac_zilog.c
index 752ef07..28269bb 100644
--- a/drivers/serial/pmac_zilog.c
+++ b/drivers/serial/pmac_zilog.c
@@ -88,9 +88,19 @@ MODULE_LICENSE("GPL");
 
 #define PWRDBG(fmt, arg...)	printk(KERN_DEBUG fmt , ## arg)
 
+#ifdef CONFIG_SERIAL_PMACZILOG_TTYS
+#define PMACZILOG_MAJOR		TTY_MAJOR
+#define PMACZILOG_MINOR		64
+#define PMACZILOG_NAME		"ttyS"
+#else
+#define PMACZILOG_MAJOR		204
+#define PMACZILOG_MINOR		192
+#define PMACZILOG_NAME		"ttyPZ"
+#endif
+
 
 /*
- * For the sake of early serial console, we can do a pre-probe
+ * FOR the sake of early serial console, we can do a pre-probe
  * (optional) of the ports at rather early boot time.
  */
 static struct uart_pmac_port	pmz_ports[MAX_ZS_PORTS];
@@ -99,9 +109,10 @@ static DEFINE_MUTEX(pmz_irq_mutex);
 
 static struct uart_driver pmz_uart_reg = {
 	.owner		=	THIS_MODULE,
-	.driver_name	=	"ttyS",
-	.dev_name	=	"ttyS",
-	.major		=	TTY_MAJOR,
+	.driver_name	=	PMACZILOG_NAME,
+	.dev_name	=	PMACZILOG_NAME,
+	.major		=	PMACZILOG_MAJOR,
+	.minor		=	PMACZILOG_MINOR,
 };
 
 
@@ -1776,7 +1787,7 @@ static void pmz_console_write(struct console *con, const char *s, unsigned int c
 static int __init pmz_console_setup(struct console *co, char *options);
 
 static struct console pmz_console = {
-	.name	=	"ttyS",
+	.name	=	PMACZILOG_NAME,
 	.write	=	pmz_console_write,
 	.device	=	uart_console_device,
 	.setup	=	pmz_console_setup,
@@ -1800,7 +1811,6 @@ static int __init pmz_register(void)
 	
 	pmz_uart_reg.nr = pmz_ports_count;
 	pmz_uart_reg.cons = PMACZILOG_CONSOLE;
-	pmz_uart_reg.minor = 64;
 
 	/*
 	 * Register this driver with the serial core

-- 
dwmw2

Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[Paul Mackerras]

David Woodhouse writes:

> OK, how about a config option to preserve the old behaviour...

Well, that's a start but it doesn't provide a migration path.

Is it possible to have the pmac_zilog ports registered both with the
new number and with the old number (assuming it's not already taken)?
That way people can move over gradually.

Paul.

Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[David Woodhouse]

On Thu, 2007-04-05 at 09:48 +1000, Paul Mackerras wrote:
> David Woodhouse writes:
> 
> > OK, how about a config option to preserve the old behaviour...
> 
> Well, that's a start but it doesn't provide a migration path.
> 
> Is it possible to have the pmac_zilog ports registered both with the
> new number and with the old number (assuming it's not already taken)?
> That way people can move over gradually.

The new option was intended to provide a way to retain the old behaviour
for systems where the kernel is updated but userspace must remain
unchanged (for some reason I can't quite imagine right now).

For _migration_, I think we can handle it better in userspace.

Anyone who builds their own kernel can also manage to change one or two
scripts or configuration files which currently refer to ttyS0. The only
case where the question of migration really holds any water is for
distributions.

In Fedora, pmac_zilog has never worked -- the module always failed to
load because 8250 was built-in. So it's an easy choice there -- we just
switch over and it's fixed.

Other distributions which change over to the fixed behaviour, if they
want 8250 and z8530 ports to co-exist, can provide a udev rule which
creates a symlink from ttySn->ttyPZ0 for backwards compatibility.

Of course, the _numbers_ might change -- a given port might no longer be
ttyS0 but ttyS1. But we're happy to overlook that one even though the
effect on the user is identical, right?

That doesn't address the fact that the 'console=' kernel command line
argument needs changes. But in general, users who are that non-technical
don't use serial consoles, and those who do can cope with this.

I think perhaps we should add this new config option to the
feature-removal-schedule right now, and take it out after a year or so.
That should be plenty of time for people to upgrade.

-- 
dwmw2

Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[Paul Mackerras]

David Woodhouse writes:

> Of course, the _numbers_ might change -- a given port might no longer be
> ttyS0 but ttyS1. But we're happy to overlook that one even though the
> effect on the user is identical, right?

Why would the numbers be prone to change, any more than they are
already?

Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[David Woodhouse]

On Fri, 2007-04-06 at 08:53 +1000, Paul Mackerras wrote:
> Why would the numbers be prone to change, any more than they are
> already?

Because now 8250 ports can actually coexist with Zilog ports. Before my
fix, it was strictly one or the other.

-- 
dwmw2

Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[Atsushi Nemoto]

On Wed, 04 Apr 2007 10:19:43 -0400, David Woodhouse <dwmw2@infradead.org> wrote:
> +#ifdef CONFIG_SERIAL_PMACZILOG_TTYS
> +#define PMACZILOG_MAJOR		TTY_MAJOR
> +#define PMACZILOG_MINOR		64
> +#define PMACZILOG_NAME		"ttyS"
> +#else
> +#define PMACZILOG_MAJOR		204
> +#define PMACZILOG_MINOR		192
> +#define PMACZILOG_NAME		"ttyPZ"
> +#endif

Is major 204 minor 192 already allocated?

Few weeks ago, I sent a patch to allocate 192...199 for other serial
driver (Subject: [PATCH 2.6.21-rc3] serial: Allocate minor device
numbers for serial_txx9 driver):

http://lkml.org/lkml/2007/3/13/246

And it is already in -mm tree since 2.6.21-rc4-mm1.  I just CC-ed the
patch to device@lanana.org, but I really do not know how "master"
devices.txt updated finally.  If I should take some further action to
lanana.org or someone, please let me know.  Thank you.

---
Atsushi Nemoto

Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[David Woodhouse]

On Thu, 2007-04-05 at 23:31 +0900, Atsushi Nemoto wrote
> Is major 204 minor 192 already allocated?

Of course. The reason it took so long to provide this patch after the
'pmac_zilog doesn't load' bug got reported was because I was waiting for
the new allocation.

> Few weeks ago, I sent a patch to allocate 192...199 for other serial
> driver 

Were those numbers assigned to you or did you just make them up?

-- 
dwmw2

Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[Atsushi Nemoto]

On Thu, 05 Apr 2007 10:47:15 -0400, David Woodhouse <dwmw2@infradead.org> wrote:
> > Is major 204 minor 192 already allocated?
> 
> Of course. The reason it took so long to provide this patch after the
> 'pmac_zilog doesn't load' bug got reported was because I was waiting for
> the new allocation.
> 
> > Few weeks ago, I sent a patch to allocate 192...199 for other serial
> > driver 
> 
> Were those numbers assigned to you or did you just make them up?

What I did is just send a patch includeing devices.txt changes to
lkml, device@lanana.org, and some others.

Maybe I should have sent "request" (not patch) mail to
device@lanana.org first?

---
Atsushi Nemoto

Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[David Woodhouse]

On Fri, 2007-04-06 at 00:09 +0900, Atsushi Nemoto wrote:
> 
> What I did is just send a patch includeing devices.txt changes to
> lkml, device@lanana.org, and some others.
> 
> Maybe I should have sent "request" (not patch) mail to
> device@lanana.org first?

Well, that's what it says right underneath the line in devices.txt which
says:
	**** DEVICE DRIVERS AUTHORS PLEASE READ THIS ****

It goes on to say...

"Third, please don't assume that the distributed version of the list is
up to date.  Due to the number of registrations I have to maintain it
in "batch mode", so there is likely additional registrations that
haven't been listed yet."

-- 
dwmw2

Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[Atsushi Nemoto]

On Thu, 05 Apr 2007 11:18:12 -0400, David Woodhouse <dwmw2@infradead.org> wrote:
> > Maybe I should have sent "request" (not patch) mail to
> > device@lanana.org first?
> 
> Well, that's what it says right underneath the line in devices.txt which
> says:
> 	**** DEVICE DRIVERS AUTHORS PLEASE READ THIS ****
> 
> It goes on to say...
> 
> "Third, please don't assume that the distributed version of the list is
> up to date.  Due to the number of registrations I have to maintain it
> in "batch mode", so there is likely additional registrations that
> haven't been listed yet."

Thank you, I see.  I'll revoke the patch in -mm tree and send a
request for minor numbers.

---
Atsushi Nemoto

Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[Geert Uytterhoeven]

On Thu, 5 Apr 2007, David Woodhouse wrote:
> On Thu, 2007-04-05 at 23:31 +0900, Atsushi Nemoto wrote
> > Is major 204 minor 192 already allocated?
> 
> Of course. The reason it took so long to provide this patch after the
> 'pmac_zilog doesn't load' bug got reported was because I was waiting for
> the new allocation.

What about the moratorium on newly assigned numbers?
What about using a dynamically allocated number?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: David Woodhouse <dwmw2@infradead.org>
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 do.

David, do this.  Fly to Portland, drive over to Linus's house, once he
lets you in, tell him to walk up to his computer and run 'cat' on the
primary serial port.  Do all of this before he reads this thread. :-)

What device name do you think he will type in?

Will he type a different device name on his PowerPC box than he will
on his x86 systems?

I think he will type /dev/ttyS0 in both cases, and it won't be because
he knows what kind of serial port controller is in either machine.

It's that simple.

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.

Try desktop systems that lots of users actually use.  Ask them what
the serial device file is.  Ask them if they had to know what
serial controller they have in their computer in order to figure
that out.

> That's what you get when you abuse device numbers belonging to
> another driver.

No, it's what you get whan drivers of the same major number do
not cooperate with minor number allocations.

Add a notion of onboard serial controllers and a properly coordinated
minor number allocation system for /dev/ttyS0 if you want to solve this.

As it stands your patch is a non-starter because it breaks a user
visible API, and people's machines won't bootup or have a console
any longer.  Or, if the powerpc machine is at Alan's house his
model trains might stop working :-)

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Russell King]

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.
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, ttySA, ttyPXA, ttyAMA, and so
the list goes on.  It apparantly gives their support department
real headaches.

There are similar feelings from the handhelds.org community.

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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: Russell King <rmk+lkml@arm.linux.org.uk>
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 ordered and using /dev/ttyS0, with a proper matching
console selection.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Russell King]

On Wed, Apr 04, 2007 at 01:43:30AM -0700, David Miller wrote:
> From: Russell King <rmk+lkml@arm.linux.org.uk>
> 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 ordered and using /dev/ttyS0, with a proper matching
> console selection.

Well yes, but it seems to have code in the architecture's early
command line parsing to parse the "console=" argument to set this
magical "serial_console" variable.

Is this an approach you recommend for all architectures?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: Russell King <rmk+lkml@arm.linux.org.uk>
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, but it seems to have code in the architecture's early
> command line parsing to parse the "console=" argument to set this
> magical "serial_console" variable.
> 
> Is this an approach you recommend for all architectures?

The platform should use whatever is appropriate, and matches
firmware/bios/whatever conventions, to determine this stuff.

On Sparc you get an openfirmware environment variable called
"output-device" that can point to a framebuffer or serial
console device.

The user can override this on the kernel command line, of course, and
what they ask for will get translated properly.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Theodore Tso]

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, ttySA, ttyPXA, ttyAMA, and so
> the list goes on.  It apparantly gives their support department
> real headaches.
> 
> There are similar feelings from the handhelds.org community.
> 
> 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.

It is certainly technically doable.  The problem is that there's a lot
of hard work between where we are and there, and serial ports have
never been important enough so that somoene has been able to justify
the intensive amounts of work to get there.

What I've always wanted to do if I could clone myself and/or had
unlimited amounts of time/funding to work on the problem, is that a
huge amount of what is in the "serial layer" needs to be pushed into
the tty layer (and things like the hangup code needs to be pushed into
VFS as revoke(2), for which thankfully we're starting to see patches
that do this).  Essentially, there is a huge amount of *hair* in the
8250 driver which really should have gone into tty layer, and some of
the hair (like locked termios, the last remants of callout device
support, etc.) should just be removed.

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 assign specific controllers/ports to specific /dev/ttySx devices.
We could also provide a registration system to allow on-line
configuration of non-probeable serial cards attached to primitive
buses that don't alllow probing, such as the ISA bus, although perhaps
that's much less important in this day and age.

The bottom line is thre's a huge amount of history and legacy in the
serial driver, but it hasn't been as _important_ for it to get the
kind of modern rewrite that we've had in our other device subsystems.
And such a rewrite is something that really evolve, but needs to be a
big-bang reorganization, and that's something rather painful that we
don't do as well as the gradual evolution approach.  But it works well
enough, and hey, my laptop doesn't even have any serial ports (unless
I plug in a USB serial card or I dock it in my docking station), and
after all, all right-thinking serial ports are implemented using
8250-derived UART's, so the current system has been Good Enough for
the vast majority of Linux users.  (And as Linus will tell you, he's a
big fan of the Good Enough/"Worse is Better"/New Jersey approach as
opposed to the equisitely overdesigned MIT/Stanford approach.)

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 maintainer; Russell ripped it out when he became the
serial maintainer; but now that he's no longer the serial maintainer,
he doesn't get to complain about that any more :-)

So my suggestion would be to simply submit patch to share minor
numbers directly to Linus/Andrew (since there is no current serial
maintainer) and see if they accept it.

Regards,

					- Ted

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Russell King]

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 maintainer; Russell ripped it out when he became the
> serial maintainer; but now that he's no longer the serial maintainer,
> he doesn't get to complain about that any more :-)

The problem with that approach was that it was being extended to more
and more drivers in the ARM world, creating an #ifdef mess in the
serial driver.

Moreover, it provided *no* way to select an 8250-based serial port in
the presence of a "foreign" port claiming the ttyS console namespace.
Utterly unacceptable when you have a real environment of mixed serial
port types.

IOW, it was utterly broken.  It prevented me from doing the things I
wanted to do.

The only real answer is to fix the problem *properly*.  Hacks just end
up breaking peoples setups.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[H. Peter Anvin]

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 assign specific controllers/ports to specific /dev/ttySx devices.
> We could also provide a registration system to allow on-line
> configuration of non-probeable serial cards attached to primitive
> buses that don't alllow probing, such as the ISA bus, although perhaps
> that's much less important in this day and age.
> 

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.

Then the ones who want static mapping can still have them.  This would 
presumably work with early remapping in open(), similar to the way ptmx 
is done.

Of course, now you have the potential of aliasing, again, which tends to 
cause all kinds of headaches w.r.t. locking.  From that perspective, it 
would be better if udev made symlinks, and we made the kernel use some 
sort of discovery syntax for console= (say, "console=serial0" to hunt 
down the "first" serial port for some definition thereof.)

	-hpa

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Alan Cox]

> 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 worse than simply starting the 8250 ports at a
platform specific minor offset.

Alan

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Theodore Tso]

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 the ones that really want dynamic mapping.

> Of course, now you have the potential of aliasing, again, which tends to 
> cause all kinds of headaches w.r.t. locking.  

That would break the 99.9% of the the world using Intel-based systems
which only have 8250's, for very little gain. 

Like it or not, /dev/ttySx and 8250 UART's are to serial ports what
the PCI is to system buses....

						- Ted

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Russell King]

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* as a serial port multiplexer which maps in 
> > all the types, for the ones that really want dynamic mapping.
> 
> > Of course, now you have the potential of aliasing, again, which tends to 
> > cause all kinds of headaches w.r.t. locking.  
> 
> That would break the 99.9% of the the world using Intel-based systems
> which only have 8250's, for very little gain. 
> 
> Like it or not, /dev/ttySx and 8250 UART's are to serial ports what
> the PCI is to system buses....

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 map these new chardevs
to the real serial ports.

*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 ports and 8250 ports suddenly becomes realistic.

Continue ignoring that problem and this thread will just grow with zero
real progress.

I'm repeating myself though.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

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 map these new chardevs
> to the real serial ports.
> 
> *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 ports and 8250 ports suddenly becomes realistic.
> 
> Continue ignoring that problem and this thread will just grow with zero
> real progress.
>
> I'm repeating myself though.

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. 

Separate device names work just fine. It's simpler, and for many people
it's preferable because it gives more repeatability to device names.
With the current patch I _know_ that ttyPZ0 is the built-in z8530
controller and ttyS0 is the PCMCIA modem, for example.

The argument that people shouldn't need to know what type of port they
have is a red herring. They're going to have to work out what _number_
it is anyway, and sharing the major numbers just makes that _harder_.
 
Graphical tools are also a red herring -- if the graphical tools are
broken and don't show non-8250 ports, then they can be fixed.

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Paul Mackerras]

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 a completely pointless waste of time
and effort?  Linux is ready for the desktop?  Suuuure it is...

Paul.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Russell King]

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 pointless
> > waste of time and effort. 
> 
> Avoiding breaking userspace is a completely pointless waste of time
> and effort?  Linux is ready for the desktop?  Suuuure it is...

And what contribution to achieving the goal of having a single namespace
does the above comment provide?

Look, this is what I'm complaining about.  There's lots of talk on this
issue.  There's been lots and lots of talk on this issue in the past as
well.  I've raised the technical issues in this thread several times and
so far been ignored every time.

If as much effort went into trying to resolve the technical problems as
has gone into whinging about it in this thread, maybe the goal would be
a little closer?

I'm sorry if you find this message offensive.  I find filling my mailbox
with 80ish messages of whinging utterly unproductive and equally offensive
especially given my past input on serial issues.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Olivier Galibert]

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 ports and 8250 ports suddenly becomes realistic.

Ok, so that I understand correctly, your problem is with the
tty_register_driver interface as used in
serial_core:uart_register_driver, correct?

Looking at the function, I understand why.
{alloc,register}_chrdev_region is very, very not designed to be
fully dynamic it seems.

  OG.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Pavel Machek]

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 respect -- it's basically pmac_zilog and some Sun
> UARTs, isn't it?
> 
> And even if it _were_ true, it wouldn't be a particularly good reason
> for changing the way we handle serial ports under Linux.
> 
> > > > The built-in ports can generally be enumerated early on boot in a
> > > > stable order, and they should be assigned the low ttySn numbers,
> > > > regardless of what chip is used to implement them. 
> > > 
> > > 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 other than 8250 ports.
> >
> > 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

Actually I thought that it was a typo when I seen ttySA0 on
openmoko... 

(Which is mostly offtopic here, because the fix for zilog is obviously
needed).

Did not linus say something like 'all devices of one type should use
similar name), in some sata debate?
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: David Woodhouse <dwmw2@infradead.org>
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.

Dynamic minor number allocation for ttyS? would allow this
just fine, and that's exactly what we do on sparc as I
explained in another response.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Benjamin Herrenschmidt]

On Tue, 2007-04-03 at 16:56 -0700, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> 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.
> 
> Dynamic minor number allocation for ttyS? would allow this
> just fine, and that's exactly what we do on sparc as I
> explained in another response.

If we can get it past whoever is the current 8250 maintainer, then fine
with me. Back then, I hit a brick wall.

Ben.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Paul Mackerras]

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 those plus a whole pile of others, but
neither found the /dev/ttyPZ[01] that I get with your patch applied.
Gnome-ppp at least let me type in /dev/ttyPZ0, but kppp didn't seem to
have that facility.

> And nobody _forces_ you to use the name ttyPZ0. If you really want, you
> can call it ttyS0.... just mknod /dev/ttyS0 204 192

Sure I can do that, but that's beyond a non-technical user, who is
precisely the person who won't know (and shouldn't have to know) that
their computer has an 85C30 chip rather than a 16C550, or even what
those numbers refer to.

Paul.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

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.  Gnome-ppp offers just /dev/modem and
> /dev/ttyS[0123].  Kppp offers those plus a whole pile of others, but
> neither found the /dev/ttyPZ[01] that I get with your patch applied.
> Gnome-ppp at least let me type in /dev/ttyPZ0, but kppp didn't seem to
> have that facility.

shinybook /shiny/git/olpc-2.6 $ ls /dev/tty[a-zA-Z]* 
/dev/ttyPZ0  /dev/ttyPZ1  /dev/ttyS0  /dev/ttyS1  /dev/ttyS2  /dev/ttyS3

If you have dialler programs which can't manage to show you the existing
serial ports, file bugs. Especially if they don't let you type device
nodes into them. Sounds like kppp wouldn't let you use USB serial ports
either -- or phones connected directly via USB.

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: Paul Mackerras <paulus@samba.org>
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 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 it's
> /dev/ttyPZ0 not /dev/ttyS0, like it would be if the designers had used
> a 16C550".
...
> Why should a user know or care about that?  It really should be "it's
> the built-in serial port on my computer therefore it's /dev/ttyS0".

I totally agree with Paul, the onboard serial device should get
ttyS0 regardless of what hardare is used to drive it.

We dish out the minors sequentially on sparc in order to handle
the case of multiple onboard serial controllers of different
types which can happen on sparc.

Generalizing this minor number allocation for ttyS? might be the
best way to handle this.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Alan Cox]

> 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 generic "all my
serial ports" listing.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
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 console
specification on the kernel command line.

I don't care about ordering, but the name matters just like "eth%d"
is the default name for all ethernet devices.

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.

Not the least of which is the user has to scratch his head figuring
out what kind of chip drives his serial console, he just wants the
first serial port and he should have a way to say just that even
on the kernel command line.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Alan Cox]

> 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/which slot/which multiplexor.

There is a world of a difference between a serious serial port
application and "wtf has my console gone"

> Not the least of which is the user has to scratch his head figuring
> out what kind of chip drives his serial console, he just wants the
> first serial port and he should have a way to say just that even
> on the kernel command line.

Define "first". First by I/O order, by PCI scan order (and which type),
does ACPI come before or after ISA etc...

At the moment we sort of magic this for the PC by having hardcoded probe
order hacks by address, on the sparc by having other driver magic, on the
PPC by hardcoding some rules etc then hack the result to be ttyS0.

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
serious serial setup.

Alan

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
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
> serious serial setup.

If you want geographical type device specification hierarchies, to
sanely manage that kind of stuff, they belong via sysfs or something
userside like that.

Using a bunch of different majors does not help the situation you
speak of.

What if I have 1,000 cyclades cards in my system?  The cyclades
serial major number helps me diddly in that case.  What about
having 82 8250's?

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Russell King]

On Tue, Apr 03, 2007 at 06:21:25PM -0700, David Miller wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> 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 console
> specification on the kernel command line.

FACT: you can only have one struct console with one name.

FACT: If you have two struct consoles using the same name, the driver
 which wins the priviledge of console is unpredictable.

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.

There are very real issues that need fixing deep within the kernel
before you can even think about the possibility of *PROPERLY* supporting
all serial ports beneath one namespace.

Before someone whinges "we did it in 2.4" my answer is: yes, you hacked
around the problem in 2.4 creating an utter mess in the process.

If you want to see what an utter mess pushing all serial ports towards
ttyS* creates in 2.5 kernels (which will be similar for 2.6), look at
these patches:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1427/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1428/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1429/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1431/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1432/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1433/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1435/2
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1436/2

Moreover, note that the serial core is statically configured with the
*maximum* number of ports it will ever support.  Tough luck if you're
a distro and wanting to allow users to support multi-port serial cards.

Since we've been where we are for years and years, my take on this
subject has always been: we should *not* abuse any of the existing
allocations.  If we want to create a single namespace for serial ports
we should obtain a *new* allocation and migrate drivers over to that
namespace, avoiding any bastardisation of existing drivers.  Modulo
fixing the very real issues mentioned above first.

Feel free to continue whinging about it for a few more years.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Paul Mackerras]

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 "generic" serial ports will be available - as required for the
>  chardev and tty layers.

I think the thing that davem and I have in common is that we have a
data structure that the firmware gives us that (at least) enumerates
all of the on-board serial ports for us, thus we *can* know very early
in the boot process how many "generic" serial ports will be available.

> There are very real issues that need fixing deep within the kernel
> before you can even think about the possibility of *PROPERLY* supporting
> all serial ports beneath one namespace.

I don't actually want to do that; I'm perfectly happy for various
kinds of plug-in cards to each have their own namespace.  If you're
plugging in a Cyclades card for instance I think it's quite reasonable
for the ports to be named /dev/ttyCn.

It's the built-in serial ports on the motherboard where I think the
user should not have to know what sort of chip was used to implement
the serial port.  We don't require users to know whether the
manufacturer used an 8250 or a 16450 or a 16550, so why should it
matter if the manufacturer used an 8530?

BTW, are you still maintaining the serial layer?

Paul.

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Russell King]

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 have in common is that we have a
> data structure that the firmware gives us that (at least) enumerates
> all of the on-board serial ports for us, thus we *can* know very early
> in the boot process how many "generic" serial ports will be available.

Goodo.  However, that's not the case elsewhere, and the lack of that
information makes it *extremely* hard to provide any generic solution,
especially with a driver as ubiquous as the 8250 driver.

How do I know how many serial ports are connected to an ARM device?
What about that expansion pack I might decide to slip onto the back of
my ARM PDA which wasn't known about when the device was first booted
some years ago?

> > There are very real issues that need fixing deep within the kernel
> > before you can even think about the possibility of *PROPERLY* supporting
> > all serial ports beneath one namespace.
> 
> I don't actually want to do that; I'm perfectly happy for various
> kinds of plug-in cards to each have their own namespace.  If you're
> plugging in a Cyclades card for instance I think it's quite reasonable
> for the ports to be named /dev/ttyCn.

Well, Cyclades is irrelevant in this discussion because it has nothing
to do with serial_core, and therefore nothing to do with the 8250 driver,
and, therefore, nothing to do with the problem of the major 4 / ttyS
namespace.  Ergo, it's utterly irrelevant to even mention it.

> It's the built-in serial ports on the motherboard where I think the
> user should not have to know what sort of chip was used to implement
> the serial port.  We don't require users to know whether the
> manufacturer used an 8250 or a 16450 or a 16550, so why should it
> matter if the manufacturer used an 8530?

I'm going to answer this *technically*.  It's the *technicalities* that
are causing this restriction.  Solve those technicalities and the problem
goes away.

We don't require users to know if it's an 8250, 16450, 16550 because
they're all compatible with the previous models, and therefore
*technically* it makes sense for them to be driven by the same driver.

However, an 8530 isn't compatible with an 8250 and requires a separate
driver.

The restriction on serial namespace isn't *hardware* based, it's *driver*
based, and that restriction comes from the way the tty and chardev
subsystems work.  When you register a tty driver, you need to tell the
tty subsystem how many ttys that driver will *ever* support.  The only
way to change that number is to unregister all ttys connected with the
driver, unregister the driver, change the number, reallocate arrays,
re-register the driver, and re-register the ttys.

If any one of those ttys is in use, there's a problem - you have to
hangup that user and have them close/reopen the tty.  That's fairly
disruptive, especially if it happens to be a modem that some user has
dialed in from (you end up logging them out of the system every time
you need to increase the number of serial ttys).

So, you see, this is a big problem that needs *technically*
resolving *with* *patches* before we can think about having a single
serial namespace.

> BTW, are you still maintaining the serial layer?

That's irrelevant to the discussion at hand.  For the record, because
others have different opinions to me, and persisted in trying to tell
me what I should be doing without providing patches, I stepped back
from the maintainership role, and have only been reviewing the odd
patch as I see fit.

Maybe it'll be different this time around, but so far all I've seen in
this thread is lots of people providing opinions and very little code
to achieve their aims.  Or even technical *discussion* about how to go
about implementing those opinions.

Therefore, I put it to those arguing for a single serial major that the
reason it hasn't happened is that no one is *really* that bothered about
it to solve the underlying issues.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Geert Uytterhoeven]

On Tue, 3 Apr 2007, David Miller wrote:
> From: Paul Mackerras <paulus@samba.org>
> 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 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 it's
> > /dev/ttyPZ0 not /dev/ttyS0, like it would be if the designers had used
> > a 16C550".
> ...
> > Why should a user know or care about that?  It really should be "it's
> > the built-in serial port on my computer therefore it's /dev/ttyS0".
> 
> I totally agree with Paul, the onboard serial device should get
> ttyS0 regardless of what hardare is used to drive it.

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Olaf Hering]

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 changed?
What major/minor pair will the two ports get?

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

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, 192 2007-08-13 11:48 /dev/ttyPZ0
crw-rw---- 1 root uucp 204, 193 2007-08-13 11:48 /dev/ttyPZ1

-- 
dwmw2

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Olaf Hering]

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 /shiny/git/mtd-utils $ ls -l /dev/ttyPZ*
> crw-rw---- 1 root uucp 204, 192 2007-08-13 11:48 /dev/ttyPZ0
> crw-rw---- 1 root uucp 204, 193 2007-08-13 11:48 /dev/ttyPZ1

I dont see 204:192 in devices.txt

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[Olaf Hering]

On Tue, Apr 03, David Woodhouse wrote:

> There are proper device numbers registered for pmac_zilog now. Use them.

NACK.
Breaks serial console autodetection.