On Wed, Apr 04, 2007 at 07:55:30PM +1000, Paul Mackerras wrote: > Russell King writes: > > FACT: there is no way to know at any particular driver registration time > > how many "generic" serial ports will be available - as required for the > > chardev and tty layers. > > I think the thing that davem and I have in common is that we have a > data structure that the firmware gives us that (at least) enumerates > all of the on-board serial ports for us, thus we *can* know very early > in the boot process how many "generic" serial ports will be available.
Goodo. However, that's not the case elsewhere, and the lack of that information makes it *extremely* hard to provide any generic solution, especially with a driver as ubiquous as the 8250 driver. How do I know how many serial ports are connected to an ARM device? What about that expansion pack I might decide to slip onto the back of my ARM PDA which wasn't known about when the device was first booted some years ago? > > There are very real issues that need fixing deep within the kernel > > before you can even think about the possibility of *PROPERLY* supporting > > all serial ports beneath one namespace. > > I don't actually want to do that; I'm perfectly happy for various > kinds of plug-in cards to each have their own namespace. If you're > plugging in a Cyclades card for instance I think it's quite reasonable > for the ports to be named /dev/ttyCn. Well, Cyclades is irrelevant in this discussion because it has nothing to do with serial_core, and therefore nothing to do with the 8250 driver, and, therefore, nothing to do with the problem of the major 4 / ttyS namespace. Ergo, it's utterly irrelevant to even mention it. > It's the built-in serial ports on the motherboard where I think the > user should not have to know what sort of chip was used to implement > the serial port. We don't require users to know whether the > manufacturer used an 8250 or a 16450 or a 16550, so why should it > matter if the manufacturer used an 8530? I'm going to answer this *technically*. It's the *technicalities* that are causing this restriction. Solve those technicalities and the problem goes away. We don't require users to know if it's an 8250, 16450, 16550 because they're all compatible with the previous models, and therefore *technically* it makes sense for them to be driven by the same driver. However, an 8530 isn't compatible with an 8250 and requires a separate driver. The restriction on serial namespace isn't *hardware* based, it's *driver* based, and that restriction comes from the way the tty and chardev subsystems work. When you register a tty driver, you need to tell the tty subsystem how many ttys that driver will *ever* support. The only way to change that number is to unregister all ttys connected with the driver, unregister the driver, change the number, reallocate arrays, re-register the driver, and re-register the ttys. If any one of those ttys is in use, there's a problem - you have to hangup that user and have them close/reopen the tty. That's fairly disruptive, especially if it happens to be a modem that some user has dialed in from (you end up logging them out of the system every time you need to increase the number of serial ttys). So, you see, this is a big problem that needs *technically* resolving *with* *patches* before we can think about having a single serial namespace. > BTW, are you still maintaining the serial layer? That's irrelevant to the discussion at hand. For the record, because others have different opinions to me, and persisted in trying to tell me what I should be doing without providing patches, I stepped back from the maintainership role, and have only been reviewing the odd patch as I see fit. Maybe it'll be different this time around, but so far all I've seen in this thread is lots of people providing opinions and very little code to achieve their aims. Or even technical *discussion* about how to go about implementing those opinions. Therefore, I put it to those arguing for a single serial major that the reason it hasn't happened is that no one is *really* that bothered about it to solve the underlying issues. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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/
