Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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.
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 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
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.
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 <[EMAIL PROTECTED]> To: Benny Amorsen <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers. > Indeed, 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Gerhard Mack [EMAIL PROTECTED] <>< 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 <[EMAIL PROTECTED]> > To: Benny Amorsen <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers. > > > Indeed, 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 [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Gerhard Mack [EMAIL PROTECTED] <>< 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 [EMAIL PROTECTED] 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.
> 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 [EMAIL PROTECTED] 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.
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 [EMAIL PROTECTED] 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.
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 [EMAIL PROTECTED] To: Benny Amorsen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers. Indeed, 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Gerhard Mack [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
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 [EMAIL PROTECTED] To: Benny Amorsen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers. Indeed, 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Gerhard Mack [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
> "GM" == Gerhard Mack <[EMAIL PROTECTED]> writes: GM> On Wed, 4 Apr 2007, Alan Cox wrote: >> You don't get machines with 64 ethernet ports on add-in cards. >> There are good reasons for the naming schemes in use. GM> If they made them I'd build one. Indeed, port density is disappointingly poor in modern 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
GM == Gerhard Mack [EMAIL PROTECTED] writes: GM On Wed, 4 Apr 2007, Alan Cox wrote: You don't get machines with 64 ethernet ports on add-in cards. There are good reasons for the naming schemes in use. GM If they made them I'd build one. Indeed, port density is disappointingly poor in modern 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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.
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? Sre 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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? Sre it is... Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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? Sre it is... Paul. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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? Sre 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
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.
From: Russell King <[EMAIL PROTECTED]> Date: Wed, 4 Apr 2007 10:00:16 +0100 > On Wed, Apr 04, 2007 at 01:43:30AM -0700, David Miller wrote: > > Well the "bad hack" we use on sparc gives usable serial ports, > > properly ordered and using /dev/ttyS0, with a proper matching > > console selection. > > Well yes, 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
> If you want hierarchy, create it: > > /sys/blah/serial/controllerX/portY > > and keeping them all under the ttyS? major keeps the simple > cases working sanely too. Currently yes you could do that, but that would break all the back compatibility. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 charTTY devices
> 0 = /dev/tty0 Current virtual console
>
> 1 = /dev/tty1 First virtual console
> ...
> 63 = /dev/tty6363rd virtual console
> 64 = /dev/ttyS0First 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 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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.
On Wed, Apr 04, 2007 at 01:43:30AM -0700, David Miller wrote: > From: Russell King <[EMAIL PROTECTED]> > Date: Wed, 4 Apr 2007 09:38:03 +0100 > > > However, despite people pressing for it, there's yet to be a *sane* > > *technical* *solution* to the problem. All I've seen so far is one > > bad hack. > > 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 charTTY devices 0 = /dev/tty0 Current virtual console 1 = /dev/tty1 First virtual console ... 63 = /dev/tty6363rd virtual console 64 = /dev/ttyS0First 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
From: Russell King <[EMAIL PROTECTED]> Date: Wed, 4 Apr 2007 09:38:03 +0100 > However, despite people pressing for it, there's yet to be a *sane* > *technical* *solution* to the problem. All I've seen so far is one > bad hack. Well the "bad hack" we use on sparc gives usable serial ports, properly ordered and using /dev/ttyS0, with a proper matching console selection. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
From: Russell King <[EMAIL PROTECTED]> Date: Wed, 4 Apr 2007 08:52:44 +0100 > On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote: > > From: David Woodhouse <[EMAIL PROTECTED]> > > Date: Wed, 04 Apr 2007 01:19:59 -0400 > > > > > I don't see why that 'should' be the case. Certainly it _isn't_ the case > > > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
From: David Woodhouse <[EMAIL PROTECTED]> Date: Wed, 04 Apr 2007 02:03:54 -0400 > On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote: > > It 'should' be the case because that is what is easiest for users and > > makes most sense from a user's point of view. > > I really don't buy that argument. I 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 :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote: > From: David Woodhouse <[EMAIL PROTECTED]> > Date: Wed, 04 Apr 2007 01:19:59 -0400 > > > I don't see why that 'should' be the case. Certainly it _isn't_ the case > > on most supported platforms -- we have separate device numbers, and > > names, 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
On Tue, Apr 03, 2007 at 06:21:25PM -0700, David Miller wrote: > From: Alan Cox <[EMAIL PROTECTED]> > Date: Wed, 4 Apr 2007 02:19:24 +0100 > > > > I totally agree with Paul, the onboard serial device should get > > > ttyS0 regardless of what hardare is used to drive it. > > > > Thats between you and udev. > > 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
On Tue, 3 Apr 2007, David Miller wrote:
> From: David Woodhouse <[EMAIL PROTECTED]>
> Date: Wed, 04 Apr 2007 01:19:59 -0400
>
> > I don't see why that 'should' be the case. Certainly it _isn't_ the case
> > on most supported platforms -- we have separate device numbers, and
> > names, for most types of 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 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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.
On Tue, 3 Apr 2007, David Miller wrote:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Wed, 4 Apr 2007 09:14:20 +1000
>
> > David Woodhouse writes:
> >
> > > There are proper device numbers registered for pmac_zilog now. Use them.
> >
> > Sigh. I guess this is inevitable, but IMNSHO this exposes a 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 <[EMAIL PROTECTED]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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.
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
On Tue, 3 Apr 2007, David Miller wrote:
From: Paul Mackerras [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 09:14:20 +1000
David Woodhouse writes:
There are proper device numbers registered for pmac_zilog now. Use them.
Sigh. I guess this is inevitable, but IMNSHO this exposes a 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 [EMAIL PROTECTED]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
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.
On Tue, 3 Apr 2007, David Miller wrote:
From: David Woodhouse [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 01:19:59 -0400
I don't see why that 'should' be the case. Certainly it _isn't_ the case
on most supported platforms -- we have separate device numbers, and
names, for most types of 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 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
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.
On Tue, Apr 03, 2007 at 06:21:25PM -0700, David Miller wrote: From: Alan Cox [EMAIL PROTECTED] Date: Wed, 4 Apr 2007 02:19:24 +0100 I totally agree with Paul, the onboard serial device should get ttyS0 regardless of what hardare is used to drive it. Thats between you and udev. 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote: From: David Woodhouse [EMAIL PROTECTED] Date: Wed, 04 Apr 2007 01:19:59 -0400 I don't see why that 'should' be the case. Certainly it _isn't_ the case on most supported platforms -- we have separate device numbers, and names, 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
From: David Woodhouse [EMAIL PROTECTED] Date: Wed, 04 Apr 2007 02:03:54 -0400 On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote: It 'should' be the case because that is what is easiest for users and makes most sense from a user's point of view. I really don't buy that argument. I 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 :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
From: Russell King [EMAIL PROTECTED] Date: Wed, 4 Apr 2007 08:52:44 +0100 On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote: From: David Woodhouse [EMAIL PROTECTED] Date: Wed, 04 Apr 2007 01:19:59 -0400 I don't see why that 'should' be the case. Certainly it _isn't_ the case 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
From: Russell King [EMAIL PROTECTED] Date: Wed, 4 Apr 2007 09:38:03 +0100 However, despite people pressing for it, there's yet to be a *sane* *technical* *solution* to the problem. All I've seen so far is one bad hack. Well the bad hack we use on sparc gives usable serial ports, properly ordered and using /dev/ttyS0, with a proper matching console selection. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 charTTY devices 0 = /dev/tty0 Current virtual console 1 = /dev/tty1 First virtual console ... 63 = /dev/tty6363rd virtual console 64 = /dev/ttyS0First 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
On Wed, Apr 04, 2007 at 01:43:30AM -0700, David Miller wrote: From: Russell King [EMAIL PROTECTED] Date: Wed, 4 Apr 2007 09:38:03 +0100 However, despite people pressing for it, there's yet to be a *sane* *technical* *solution* to the problem. All I've seen so far is one bad hack. 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 charTTY devices
0 = /dev/tty0 Current virtual console
1 = /dev/tty1 First virtual console
...
63 = /dev/tty6363rd virtual console
64 = /dev/ttyS0First 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 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
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.
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
If you want hierarchy, create it: /sys/blah/serial/controllerX/portY and keeping them all under the ttyS? major keeps the simple cases working sanely too. Currently yes you could do that, but that would break all the back compatibility. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
From: Russell King [EMAIL PROTECTED] Date: Wed, 4 Apr 2007 10:00:16 +0100 On Wed, Apr 04, 2007 at 01:43:30AM -0700, David Miller wrote: Well the bad hack we use on sparc gives usable serial ports, properly ordered and using /dev/ttyS0, with a proper matching console selection. Well yes, 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
From: David Woodhouse <[EMAIL PROTECTED]> Date: Wed, 04 Apr 2007 01:19:59 -0400 > I don't see why that 'should' be the case. Certainly it _isn't_ the case > on most supported platforms -- we have separate device numbers, and > names, for most types of ports. There's only one or two drivers which > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
On Wed, 4 Apr 2007, Alan Cox wrote: > You don't get machines with 64 ethernet ports on add-in cards. There are > good reasons for the naming schemes in use. If they made them I'd build one. http://innerfire.net/pics/projects/21portfirewall_2.jpg Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< 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 [EMAIL PROTECTED] 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.
On Tue, 3 Apr 2007, [EMAIL PROTECTED] wrote: On Tue, 03 Apr 2007 16:09:08 PDT, Brad Boyer said: an abstraction of "serial port" as far as the user is concerned. On Solaris, I can say "/dev/term/a" and know that I will get the first serial port if it is available without needing to care if it 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
Once upon a time, Brad Boyer <[EMAIL PROTECTED]> said: >The point is that people are used to having "ttyS0" mean the first >onboard serial port. My first serial port is a USB dongle and is ttyUSB0. If the argument is that all serials should be ttyS[0-9]+, are you going to change USB adapters as well? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 pgpdiLaD8CSGA.pgp Description: PGP signature
