I've been trying to get the new serial core stuff working on a PPC 4xx
machine (an EP405 board, specifically). This is proving more
difficult than I expected.
In 8250.c, it appears that in order for a port to be used for the
serial console it must be defined "old style" with SERIAL_PORT_DFNS,
rather than being registered with register_serial() (because
serial8250_console_setup() indexs into the serial8250_ports array)).
This presents a small problem for 4xx, since it's serial ports are
memory mapped and the new old_serial_port structure can't represent
these. I added support for these into 8250.c, but ran into further
troubles.
The kernel now gets into an infinite loop when trying to open
/dev/console in init(). The loop is occuring in tty_open() - the open
fails and it loops back to the retry_open: label. This seems to be
happening because the uart_port structure is ending up with the type
field set to PORT_UNKNOWN. However, I'm getting confused attempting
to work out where this field ought to be set, and why it isn't.
The current plethora of similar-but-not-the-same structures describing
serial ports (serial_state, serial_struct, uart_port, old_serial_port)
is also rather confusing. I'm guessing some of these are deprecated
and remain only as an aid to transition, but I'm not sure which.
--
David Gibson | For every complex problem there is a
[email protected] | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
On Mon, Jul 29, 2002 at 02:08:24PM +1000, David Gibson wrote:
> I've been trying to get the new serial core stuff working on a PPC 4xx
> machine (an EP405 board, specifically). This is proving more
> difficult than I expected.
It's vital that you mention the kernel version you're using; some of
these problems sound like 2.5.28.
> In 8250.c, it appears that in order for a port to be used for the
> serial console it must be defined "old style" with SERIAL_PORT_DFNS,
> rather than being registered with register_serial() (because
> serial8250_console_setup() indexs into the serial8250_ports array)).
> This presents a small problem for 4xx, since it's serial ports are
> memory mapped and the new old_serial_port structure can't represent
> these.
There is no easy solution for this. Alan said we must not drop support
for serial console initialisation early on in the kernel setup, which
means before the memory subsystems are initialised.
> I added support for these into 8250.c, but ran into further troubles.
I suspect a 2.5.28 kernel; please confirm and we'll that it from there.
> The current plethora of similar-but-not-the-same structures describing
> serial ports (serial_state, serial_struct, uart_port, old_serial_port)
> is also rather confusing. I'm guessing some of these are deprecated
> and remain only as an aid to transition, but I'm not sure which.
I don't see there being an easy way to kill this off:
1. serial_struct is a userspace API.
2. old_serial_port glues asm/serial.h into 8250.c; asm/serial.h can't be
changed because (mainly) ppc uses it elsewhere. Other architectures
seem to do the same sort of thing.
Unless ppc and others are willing to put up with major breakage when I
change asm/serial.h, I don't see this getting cleaned up. Comments on
this area welcome.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote:
> Unless ppc and others are willing to put up with major breakage when I
> change asm/serial.h, I don't see this getting cleaned up. Comments on
> this area welcome.
Well, what changes do you have in mind?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Mon, Jul 29, 2002 at 07:44:08AM -0700, Tom Rini wrote:
> On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote:
> > Unless ppc and others are willing to put up with major breakage when I
> > change asm/serial.h, I don't see this getting cleaned up. Comments on
> > this area welcome.
>
> Well, what changes do you have in mind?
Firstly, apologies to Tom for turning this into a general discussion
mail. At the request of Tom, this message is also CC:'d to the PPC
devel lists.
There's quite a lot in here, so please, when replying edit out stuff
your not replying to. Thanks.
1. Serial port initialisation
-----------------------------
Firstly, one thing to bear in mind here is that, as Alan says "be nice
to make sure it was much earlier". I guess Alan's right, so we can get
oopsen out of the the kernel relatively easily, even when we're using
framebuffer consoles.
I'm sure Alan will enlighten us with his specific reasons if required.
There have been several suggestions around on how to fix this table:
a. architectures provide a sub-module to 8250.c which contains the
per-port details, rather than a table in serial.h. This would
ideally mean removing serial.h completely. The relevant object
would be linked into 8250.c when 8250.c is built as a module.
b. we create 8250_hub6.c, 8250_generic.c, 8250_multiport.c and friends
each containing the parameters for the specific cards and handle it
as above.
c. make it the responsibility of user space to tell the kernel about
many serial ports, and leave just the ones necessary for serial
console in the kernel. (see issue 2 below)
d. we keep serial.h, make it 8250-compatible ports only, and change
CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT
This is the simplest and least likely to break other code. On the
other hand, we end up hauling the ISA table and struct old_serial_port
into 2.6.
2. setserial API
----------------
This is actually tied closely into another issue; I'd like to get rid
of this silly idea where we're able to open serial ports that don't
exist (ie, their UART is "unknown"). This behaviour appears to be for
the benefit of setserial to allow it to modify port base addresses and
interrupt levels, etc. Removing this facility would require a new API
for such things. The best suggestion made so far is to do something
like:
# echo "add 0x2e8,3,autoconfig" >/dev/serialctl
# echo "remove 0x2e8" >/dev/serialctl
(or s,/dev/serialctl,/proc/tty/driver/serial, which pre-exists)
where we have "add ioport,irq,flags" and "remove ioport" (note that
mmio ports aren't covered here since they require ioremap games which
tends to be card specific!)
Why make this change? Well, we have quite a lot of baggage being
dragged around to support configuration of an open port and being
able to open a non-existent port. I'd really like to get rid of
this excess baggage.
3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc
---------------------------------------------------------
All the above are serial ports of various types. It has been expressed
several times that people would like to see all of them appear as
/dev/ttyS* (indeed, there was an, erm, rather heated discussion about
it a couple of years ago.) I'm going to be neutral on this point
here.
There are several issues surrounding this:
a. The serial core.c is very almost capable of handling this abstraction,
with one exception - a registered port can only be in one group at
one time. This restriction is brought about because of the way the
tty layer handles its tty ports.
(Handling dual registrations in two different majors gets _really_
messy - eg, you two built-in 16550A ports and two SA1100 ports
taking up ttyS0 to ttyS3. You then add a 16550A PCMCIA modem,
which becomes ttyS4. Oh, and the SA1100 ports are also appearing
as ttySA0 and ttySA1. _really_ messy. No thanks.)
b. serial consoles. Each hardware driver handles its serial consoles
by itself, and if you have two or more hardware drivers built in
with serial console support, you need to be able to tell them apart
with the console= kernel parameter.
Again, this could be solvable if we have one "ttyS" view of everything
(core.c would then be responsible for registering the console with
printk.c and passing the various methods off to the relevant
hardware).
c. People with many serial ports. We _could_ change the device number
allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc
device numbers so we end up with the same number of port slots
available for those with many many serial ports in their machines.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, Jul 29, 2002 at 06:17:02PM +0100, Russell King wrote:
> 1. Serial port initialisation
> -----------------------------
>
> Firstly, one thing to bear in mind here is that, as Alan says "be nice
> to make sure it was much earlier". I guess Alan's right, so we can get
> oopsen out of the the kernel relatively easily, even when we're using
> framebuffer consoles.
>
> I'm sure Alan will enlighten us with his specific reasons if required.
>
> There have been several suggestions around on how to fix this table:
>
> a. architectures provide a sub-module to 8250.c which contains the
> per-port details, rather than a table in serial.h. This would
> ideally mean removing serial.h completely. The relevant object
> would be linked into 8250.c when 8250.c is built as a module.
I think this would work best. On PPC this would allow us to change the
mess of include/asm-ppc/serial.h into a slightly cleaner Makefile
(especially if we do the automagic <platforms/platform.h> or
<asm/platform.h> bit that's been talked about in the past) magic and we
could use that object file as well in the bootwrapper as well.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Mon, Jul 29, 2002 at 10:43:41AM -0700, Tom Rini wrote:
>
> On Mon, Jul 29, 2002 at 06:17:02PM +0100, Russell King wrote:
>
>
> > 1. Serial port initialisation
> > -----------------------------
> >
> > Firstly, one thing to bear in mind here is that, as Alan says "be nice
> > to make sure it was much earlier". I guess Alan's right, so we can get
> > oopsen out of the the kernel relatively easily, even when we're using
> > framebuffer consoles.
> >
> > I'm sure Alan will enlighten us with his specific reasons if required.
> >
> > There have been several suggestions around on how to fix this table:
> >
> > a. architectures provide a sub-module to 8250.c which contains the
> > per-port details, rather than a table in serial.h. This would
> > ideally mean removing serial.h completely. The relevant object
> > would be linked into 8250.c when 8250.c is built as a module.
>
> I think this would work best. On PPC this would allow us to change the
> mess of include/asm-ppc/serial.h into a slightly cleaner Makefile
> (especially if we do the automagic <platforms/platform.h> or
> <asm/platform.h> bit that's been talked about in the past) magic and we
> could use that object file as well in the bootwrapper as well.
I think this would be the cleanest method as well. Especially when we
recognize that the asm-ppc/serial.h situation will only get worse
over time. Every embedded PPC board designer has a unique location
for his 16550 UART(s) and we just keep adding more preprocessor
cruft for each port. This should let us keep this board-specific
info in our board port files...more abstraction=good.
Regards,
--
Matt Porter
[email protected]
This is Linux Country. On a quiet night, you can hear Windows reboot.
>> a. architectures provide a sub-module to 8250.c which contains the
>> per-port details, rather than a table in serial.h. This would
>> ideally mean removing serial.h completely. The relevant object
>> would be linked into 8250.c when 8250.c is built as a module.
>
>I think this would work best. On PPC this would allow us to change the
>mess of include/asm-ppc/serial.h into a slightly cleaner Makefile
>(especially if we do the automagic <platforms/platform.h> or
><asm/platform.h> bit that's been talked about in the past) magic and we
>could use that object file as well in the bootwrapper as well.
Especially, please, let's avoid once for all statically defined table,
on PPC (specifically on pmac) the table is really dynamic, and
the "legacy ports" (if any) may not be ttyS0..1, but could well be
2..3, or higher, all this having to be decided at runtime for both
built-in driver and modular (so eraly_serial_setup isn't good).
I quite like the sub-module mecanism. I'd rather have it done the
opposite though. I don't care that much about sharing those files
with the bootloader, and i'd rather see the core serial code beeing
a submodule of the arch specific module.
Typically, that would give us:
- 8250_legacy.c would load 8250 core, probe legacy ports and
instanciate them for typical x86 setup
- 8250_ppc.c would instanciate known ports on PReP or CHRP machines
and do nothing on pmac
- 8250_pci.c would be a pci_driver and instanciate ports for a given
PCI card
- 8250_cs.c would be a pcmcia driver and instanciate ports for a
given PCMCIA modem card
etc... And of course, we can have an arbitrary set of the above loaded
instanciating ports are they are found.
Ben.
On Mon, Jul 29, 2002 at 08:13:52PM +0200, Benjamin Herrenschmidt wrote:
> >> a. architectures provide a sub-module to 8250.c which contains the
> >> per-port details, rather than a table in serial.h. This would
> >> ideally mean removing serial.h completely. The relevant object
> >> would be linked into 8250.c when 8250.c is built as a module.
> >
> >I think this would work best. On PPC this would allow us to change the
> >mess of include/asm-ppc/serial.h into a slightly cleaner Makefile
> >(especially if we do the automagic <platforms/platform.h> or
> ><asm/platform.h> bit that's been talked about in the past) magic and we
> >could use that object file as well in the bootwrapper as well.
>
> Especially, please, let's avoid once for all statically defined table,
> on PPC (specifically on pmac) the table is really dynamic, and
> the "legacy ports" (if any) may not be ttyS0..1, but could well be
> 2..3, or higher, all this having to be decided at runtime for both
> built-in driver and modular (so eraly_serial_setup isn't good).
Well, on pmac yes. But for a good hunk of the rest of the PPC world the
inital ports are static (and as long as new ports, ie pcmcia stuff, is
handled sanely anyhow, I don't think this is an issue).
> I quite like the sub-module mecanism. I'd rather have it done the
> opposite though. I don't care that much about sharing those files
> with the bootloader, and i'd rather see the core serial code beeing
> a submodule of the arch specific module.
Then how do you propose to keep the bootloader working and kill off the
ugly ugly include/asm-ppc/serial.h ?
> Typically, that would give us:
>
> - 8250_legacy.c would load 8250 core, probe legacy ports and
> instanciate them for typical x86 setup
> - 8250_ppc.c would instanciate known ports on PReP or CHRP machines
> and do nothing on pmac
> - 8250_pci.c would be a pci_driver and instanciate ports for a given
> PCI card
> - 8250_cs.c would be a pcmcia driver and instanciate ports for a
> given PCMCIA modem card
>
> etc... And of course, we can have an arbitrary set of the above loaded
> instanciating ports are they are found.
I _think_ the 8250_cs.c case is seperate in this case. But most of what
you describe would work fine in the arch-is-a-submodule case. What I
was thinking of was some makefile bits to something like:
# The true legacy ports, prep/chrp/others. With a _machine test or
# something.
serial-$(CONFIG_ALL_PPC) += legacy.o
# K2 uses the legacy locations too
serial-$(CONFIG_K2) += legacy.o
# These boards make use of iomem_base/reg shift
serial-$(CONFIG_A) += a_serial.o
serial-$(CONFIG_B) += b_serial.o
...
obj-$(CONFIG_SERIAL_8250) += $(serial-y)
Or so. Maybe with a rule to turn $(serial-y) into arch_serial.o or
something.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Benjamin Herrenschmidt wrote:
> Especially, please, let's avoid once for all statically defined table,
> on PPC (specifically on pmac) the table is really dynamic,
Since all of the discussion here has been around "standard" UARTs.....
I know Russell mentioned this, and it has been discussed in the past,
but I'm most interested in being able to include non-165xx style UARTs
in the /dev/tty<something>. Systems may be exclusively non-165xx UARTs,
or a mix of both. The problems to solve are drivers fighting over minor
device numbers and assumptions about the system console.
Thanks.
-- Dan
On Monday 29 July 2002 12:09, Dan Malek wrote:
...
> or a mix of both. The problems to solve are drivers fighting over minor
> device numbers and assumptions about the system console.
>
Drivers need not fight about minor numbers. That can be simply handled:
int get_new_serial_minor()
{
static int minor;
return minor++;
}
Any serial driver can call this when it initializes a new uart.
Hot pluggable drivers have to hang on to their minors, and
re-use.
--
Remco Treffkorn (RT445)
HAM DC2XT
[email protected] (831) 685-1201
On Mon, Jul 29, 2002 at 12:46:42PM -0700, Remco Treffkorn wrote:
> On Monday 29 July 2002 12:09, Dan Malek wrote:
> > or a mix of both. The problems to solve are drivers fighting over minor
> > device numbers and assumptions about the system console.
> >
>
> Drivers need not fight about minor numbers. That can be simply handled:
>
> int get_new_serial_minor()
> {
> static int minor;
>
> return minor++;
> }
>
> Any serial driver can call this when it initializes a new uart.
> Hot pluggable drivers have to hang on to their minors, and
> re-use.
It's a possible solution, if we get the ability for drivers to hang
on to their minors. However, I get the feeling that this isn't going
to happen before 2.6.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, Jul 29, 2002 at 06:17:02PM +0100, Russell King wrote:
> 3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc
> ---------------------------------------------------------
>
> All the above are serial ports of various types. It has been expressed
> several times that people would like to see all of them appear as
> /dev/ttyS* (indeed, there was an, erm, rather heated discussion about
> it a couple of years ago.) I'm going to be neutral on this point
> here.
I'm not. All the issues you mention below go away if we make the rule
that _all_ serial ports are /dev/ttyS*. Userspace can have symlinks to
ease the transition if necessary.
> c. People with many serial ports. We _could_ change the device number
> allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc
> device numbers so we end up with the same number of port slots
> available for those with many many serial ports in their machines.
Yep, there really are people with >256 serial ports. It'd be nice to
support them. Does anything care about the mapping from device name
to char minor? I suspect the MAKEDEV maintainer will come and squash
me if i suggest moving the mapping for the first 192 serial devices,
but we should be able to reclaim:
Chase serial card (major 17/18), the Cyclades (major 19/20), Digiboard
(major 22/23), Stallion (major 24/25), Specialix (32/33), isdn4linux
(43/44), Comtrol (46/47), SDL RISCom (48/49), Hayes (57/58), Computone
(71/72), Specialix (75/76), PAM (78/79), Comtrol VS (105/106), ISI
(112/113), Technology Concepts (148/149), Specialix RIO (154/155/156/157),
Chase Research (164/165), ACM (166/167), Moxa (172/173), SmartIO
(174/175), USB (188/189), Low-density misc serial ports (204/205),
userspace (208/209) BlueTooth (216/217), A2232 (224/225) ... holy crap,
that's a lot of char dev space ;-) 52 majors.. think what those must
be worth on the open market ;-)
My only real objection (and it's a problem we have at the moment!) is
that serial ports then become like ethernet interfaces. Add or remove a
card and everything changes number. Somehow we already survive with this.
I was very careful when adding a new SIIG 4-port serial card to my console
server the other day to notice which card was first in PCI bus scan
order and make sure all my existing machines were hooked up to that one.
The solution to this has to be to name devices by PCI bus ID, but this is
an argument for an entirely different thread ;-)
--
Revolutions do not require corporate support.
On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote:
> On Mon, Jul 29, 2002 at 02:08:24PM +1000, David Gibson wrote:
> > I've been trying to get the new serial core stuff working on a PPC 4xx
> > machine (an EP405 board, specifically). This is proving more
> > difficult than I expected.
>
> It's vital that you mention the kernel version you're using; some of
> these problems sound like 2.5.28.
Sorry. I'm working off the linuxppc-2.5 BK tree, which is currently
at 2.5.29.
> > In 8250.c, it appears that in order for a port to be used for the
> > serial console it must be defined "old style" with SERIAL_PORT_DFNS,
> > rather than being registered with register_serial() (because
> > serial8250_console_setup() indexs into the serial8250_ports array)).
> > This presents a small problem for 4xx, since it's serial ports are
> > memory mapped and the new old_serial_port structure can't represent
> > these.
>
> There is no easy solution for this. Alan said we must not drop support
> for serial console initialisation early on in the kernel setup, which
> means before the memory subsystems are initialised.
>
> > I added support for these into 8250.c, but ran into further troubles.
>
> I suspect a 2.5.28 kernel; please confirm and we'll that it from there.
2.5.29 based BK, actually.
> > The current plethora of similar-but-not-the-same structures describing
> > serial ports (serial_state, serial_struct, uart_port, old_serial_port)
> > is also rather confusing. I'm guessing some of these are deprecated
> > and remain only as an aid to transition, but I'm not sure which.
>
> I don't see there being an easy way to kill this off:
>
> 1. serial_struct is a userspace API.
Ok.
> 2. old_serial_port glues asm/serial.h into 8250.c; asm/serial.h can't be
> changed because (mainly) ppc uses it elsewhere. Other architectures
> seem to do the same sort of thing.
I think PPC's use of asm/serial.h in the bootloader needs to go away
anyway. Could old_serial_port at least change base_baud to baud_base
to match serial_struct and serial_state. That way a designated
initializer will work in either context.
> Unless ppc and others are willing to put up with major breakage when I
> change asm/serial.h, I don't see this getting cleaned up. Comments on
> this area welcome.
Well, the machines I'm working on are totally broken now, so...
--
David Gibson | For every complex problem there is a
[email protected] | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
From: Russell King <[email protected]>
Date: Mon, 29 Jul 2002 18:17:02 +0100
d. we keep serial.h, make it 8250-compatible ports only, and change
CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT
This is the simplest and least likely to break other code. On the
other hand, we end up hauling the ISA table and struct old_serial_port
into 2.6.
My only suggestion here is that, whatever you do, if you keep
serial.h rename it to serial8250.h or similar thanks :-)
b. serial consoles. Each hardware driver handles its serial consoles
by itself, and if you have two or more hardware drivers built in
with serial console support, you need to be able to tell them apart
with the console= kernel parameter.
Again, this could be solvable if we have one "ttyS" view of everything
(core.c would then be responsible for registering the console with
printk.c and passing the various methods off to the relevant
hardware).
On many platforms we know exactly which serial port is for
the console because this is set in some firmware variable.
For others we could say "it's ttyS0 unless stated otherwise
in console=" as one possible solution.
Hey while we're on this topic. While converting over the sparc
drivers I've come to the conclusion that the serial console write
should be interrupt driven just like any other serial port TX. The
con->write() algorithm in such a scheme would look something like:
static void
fooserial_console_write(struct console *con, const char *s,
unsigned int count)
{
struct uart_fooserial_port *up = CON_TO_UART(con);
unsigned long flags;
int i, true_count;
true_count = count;
for (i = count - 1; i >= 0; i--) {
if (s[i] == '\n')
true_count++;
}
spin_lock_irqsave(up, flags);
poll_until_xmit_buffer_bytes_free(up, true_count);
append_con_buffer_to_xmit_tail(up, s, count);
spin_unlock_irqrestore(up, flags);
}
The reason it is done with this "poll until enough space" mechanism
is because we can't sleep.
Upon further consideration this does have some problems. Because of
the silly '\n' handling this means we have to make sure printk
console output cannot give us more than 1/2 the xmit buffer size
in a single write call else we could potentially never have enough
space free to do the whole write. We could size the xmit buffer
appropriately for console uart instances, using some value from
the console layer, to solve this. Or we could make con->write()
calls limit how much they give at one call. We could indicate this
limit in con->write_max or similar.
From: Remco Treffkorn <[email protected]>
Date: Mon, 29 Jul 2002 12:46:42 -0700
Drivers need not fight about minor numbers. That can be simply handled:
int get_new_serial_minor()
{
static int minor;
return minor++;
}
Any serial driver can call this when it initializes a new uart.
Hot pluggable drivers have to hang on to their minors, and
re-use.
I don't think it's wise to make hot-plug drivers keep track
of the minors they ever use in such a sloppy way. Why not
make the get_new_serial_minor() thing have a release method
too and then we can keep track of minor allocation in one
place.
Also if I remmove the module for a serial port driver, those minors
should get reused by the next registered uart too.
Finally we can name this all /dev/serialXXX in keeping with Linus's
grand view of /dev/diskXXX et al. (and keeping ttySfoo around for
compat sake for a little while of course :).
On Monday 29 July 2002 19:54, David S. Miller wrote:
> From: Remco Treffkorn <[email protected]>
> Date: Mon, 29 Jul 2002 12:46:42 -0700
>
> Drivers need not fight about minor numbers. That can be simply handled:
>
> int get_new_serial_minor()
> {
> static int minor;
>
> return minor++;
> }
>
> Any serial driver can call this when it initializes a new uart.
> Hot pluggable drivers have to hang on to their minors, and
> re-use.
>
> I don't think it's wise to make hot-plug drivers keep track
> of the minors they ever use in such a sloppy way. Why not
> make the get_new_serial_minor() thing have a release method
> too and then we can keep track of minor allocation in one
> place.
>
> Also if I remmove the module for a serial port driver, those minors
> should get reused by the next registered uart too.
Point taken.
Here are a few more points.
The given solution presents almost zero overhead, but has the mentioned
problem. There is a way to allocate and free minor numbers, but that requires
storage. It could be handled like the fd_set's select uses. Just a bit field.
Bit cleared == minor available, bit set == in use.
If you want to do that, you would want to know the maximum number of minors
used. Also, finding the first cleared bit in your field costs more on some
platforms, than on others.
Although I suspect this additional overhead to not matter much, since
initialising a new uart is a rare event, I have bin surprised in the past.
So:
How many minors?
Is the overhead in getting a minor acceptable?
Is it worth doing?
Cheers,
Remco
--
Remco Treffkorn (RT445)
HAM DC2XT
[email protected] (831) 685-1201
On Mon, 29 Jul 2002, David S. Miller wrote:
> Finally we can name this all /dev/serialXXX in keeping with Linus's
> grand view of /dev/diskXXX et al. (and keeping ttySfoo around for
> compat sake for a little while of course :).
Amen!
Nicolas
On Tue, 30 Jul 2002, Remco Treffkorn wrote:
> Is the overhead in getting a minor acceptable?
Come on! Is actually getting a minor for your serial ports, which only
happens at registration time, a really big bottleneck on your system?
Nicolas
On Tue, Jul 30, 2002 at 11:23:47AM -0700, Remco Treffkorn wrote:
> The given solution presents almost zero overhead, but has the mentioned
> problem. There is a way to allocate and free minor numbers, but that requires
> storage. It could be handled like the fd_set's select uses. Just a bit field.
> Bit cleared == minor available, bit set == in use.
core.c already knows which "slots" are in use and which aren't, so
allocation and freeing of minor numbers isn't that much of a problem.
The sole purpose behind this is to solicit is peoples opinions and
ideas on those three points I've raised.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, Jul 29, 2002 at 11:19:27PM +0100, Matthew Wilcox wrote:
> I'm not. All the issues you mention below go away if we make the rule
> that _all_ serial ports are /dev/ttyS*. Userspace can have symlinks to
> ease the transition if necessary.
Might I suggest that each driver then have a character code after the
ttyS before the numbering starts? Then each driver could sanely number
its own devices and not worry about confict with another driver.
Also, drivers that have the potential for large port counts might best
provide their own node creation methods instead of relying upon MAKEDEV
to know about all the nodes it might need at any given time.
The last driver I worked upon (the Digi dgdm driver) exported the nodes
it wanted made in /proc and the rc script that came with the driver built
them at each boot in accordance with the product that the driver detected.
> > c. People with many serial ports. We _could_ change the device number
> > allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc
> > device numbers so we end up with the same number of port slots
> > available for those with many many serial ports in their machines.
>
> Yep, there really are people with >256 serial ports. It'd be nice to
> support them. Does anything care about the mapping from device name
> to char minor? I suspect the MAKEDEV maintainer will come and squash
> me if i suggest moving the mapping for the first 192 serial devices,
> but we should be able to reclaim:
>
> Chase serial card (major 17/18), the Cyclades (major 19/20), Digiboard
> (major 22/23), Stallion (major 24/25), Specialix (32/33), isdn4linux
> (43/44), Comtrol (46/47), SDL RISCom (48/49), Hayes (57/58), Computone
> (71/72), Specialix (75/76), PAM (78/79), Comtrol VS (105/106), ISI
> (112/113), Technology Concepts (148/149), Specialix RIO (154/155/156/157),
> Chase Research (164/165), ACM (166/167), Moxa (172/173), SmartIO
> (174/175), USB (188/189), Low-density misc serial ports (204/205),
> userspace (208/209) BlueTooth (216/217), A2232 (224/225) ... holy crap,
> that's a lot of char dev space ;-) 52 majors.. think what those must
> be worth on the open market ;-)
Last I heard when I was working at Digi on the Digiboard driver, they wanted
to pull that driver out of the kernel entirely and support it on their own
(and none of the other drivers Digi distributes currently default to 22/23,
they tend to start at 70 and use as many as 10 minors, depending on the
port count).
> My only real objection (and it's a problem we have at the moment!) is
> that serial ports then become like ethernet interfaces. Add or remove a
> card and everything changes number. Somehow we already survive with this.
> I was very careful when adding a new SIIG 4-port serial card to my console
> server the other day to notice which card was first in PCI bus scan
> order and make sure all my existing machines were hooked up to that one.
>
> The solution to this has to be to name devices by PCI bus ID, but this is
> an argument for an entirely different thread ;-)
Agreed... but you have to consider other busses as well and incorporate
them into the naming scheme -- SCSI, USB, and Ethernet spring immediately
to mind.
It's my opinion that most people can get along well enough if the devices
are at least named consistently from boot to boot, but it would be nice
to have something a bit more stable than that so that adding and removing
units didn't change the device names.
It's not that important when you only have a couple boards, but some of
the drivers I worked on supported as many as 1024 units over ethernet..
and another 8 SCSI busses worth locally.. having one unit inserted into
the middle changing the order of half or more of the units would really
be a bad thing with such an installation.
Digi tried to make most of their nodes in a sub directory (/dev/digi/dgdm
or /dev/digi/els for example) and then link just the ttyS* nodes back up
into /dev
For large device counts (the dgdm driver made 5 nodes per physical port),
that's a sane way to go about IMHO.
Jeff Randall
(note: I'm no longer at Digi, I speak for myself, etc)
--
[email protected] "It's a big world and you can hit it with any airplane."
-- Flying, August 2000, Page 90.