LinuxLists.cc - Serial Driver Name Question (kernels 2.4.x)

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Ivan Passos wrote:
>
> (Please CC your answer to me, as I'm not a subscriber of this list.)
>
> Hello,
>
> By looking at tty_io.c:_tty_make_name(), it seems that the TTY
> subsystem in the Linux 2.4.x kernel series expects driver.name to be
> in the form "ttyX%d", even if you're not using devfs. I say that
> because as of now the definition in serial.c for this variable is:
>
> #if defined(CONFIG_DEVFS_FS)
> serial_driver.name = "tts/%d";
> #else
> serial_driver.name = "ttyS";
> #endif
>
> , when it seems it should be:
>
> #if defined(CONFIG_DEVFS_FS)
> serial_driver.name = "tts/%d";
> #else
> serial_driver.name = "ttyS%d";
> #endif
>

I don't think so. Some quick grepping indicates that _all_
tty drivers currently use the "ttyS" equivalent if !CONFIG_DEVFS.

Instead, it appears that someone broke tty_name(). Here's the
2.2 kernel's version:

char *tty_name(struct tty_struct *tty, char *buf)
{
if (tty)
sprintf(buf, "%s%d", tty->driver.name, TTY_NUMBER(tty));
else
strcpy(buf, "NULL tty");
return buf;
}

And that's much more sensible. The tty has a name associated with
what it is (eg "ttyS") - correlates with major number, probably.
And it has an instance number.

Which is cleaner, IMO, than embedding printf control strings
in the driver name.

--- linux-2.4.18-pre1/drivers/char/tty_io.c Wed Dec 26 11:47:40 2001
+++ linux-akpm/drivers/char/tty_io.c Wed Jan 2 20:39:53 2002
@@ -194,7 +194,7 @@ _tty_make_name(struct tty_struct *tty, c
if (!tty) /* Hmm. NULL pointer. That's fun. */
strcpy(buf, "NULL tty");
else
- sprintf(buf, name,
+ sprintf(buf, "%s%d", name,
idx + tty->driver.name_base);

return buf;

Does this look (and work) OK to you?

-

2002-01-03 06:38:24

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Andrew Morton writes:
> Ivan Passos wrote:
> >
> > (Please CC your answer to me, as I'm not a subscriber of this list.)

And when sending a message to the list about devfs, I wish people
would Cc: me.

> > Hello,
> >
> > By looking at tty_io.c:_tty_make_name(), it seems that the TTY
> > subsystem in the Linux 2.4.x kernel series expects driver.name to be
> > in the form "ttyX%d", even if you're not using devfs. I say that
> > because as of now the definition in serial.c for this variable is:
> >
> > #if defined(CONFIG_DEVFS_FS)
> > serial_driver.name = "tts/%d";
> > #else
> > serial_driver.name = "ttyS";
> > #endif
> >
> > , when it seems it should be:
> >
> > #if defined(CONFIG_DEVFS_FS)
> > serial_driver.name = "tts/%d";
> > #else
> > serial_driver.name = "ttyS%d";
> > #endif
>
> I don't think so. Some quick grepping indicates that _all_
> tty drivers currently use the "ttyS" equivalent if !CONFIG_DEVFS.
>
> Instead, it appears that someone broke tty_name(). Here's the
> 2.2 kernel's version:

That "someone" was me, and I changed it from broken to fixed.

> char *tty_name(struct tty_struct *tty, char *buf)
> {
> if (tty)
> sprintf(buf, "%s%d", tty->driver.name, TTY_NUMBER(tty));
> else
> strcpy(buf, "NULL tty");
> return buf;
> }
>
> And that's much more sensible. The tty has a name associated with
> what it is (eg "ttyS") - correlates with major number, probably.
> And it has an instance number.
>
> Which is cleaner, IMO, than embedding printf control strings
> in the driver name.

No, originally tty_name() did it, and then I shifted it to the
drivers. I don't recall the reason, but it was necessary. So I don't
want this changed.

Regards,

Richard....
Permanent: [email protected]
Current: [email protected]

2002-01-03 07:08:42

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Richard Gooch wrote:
>
> > Instead, it appears that someone broke tty_name(). Here's the
> > 2.2 kernel's version:
>
> That "someone" was me, and I changed it from broken to fixed.
>

Look at serial.c:

#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
serial_driver.name = "tts/%d";
#else
serial_driver.name = "ttyS";
#endif

tty_name will just print "ttyS". So the transition for this case
was fixed->broken.

>
> No, originally tty_name() did it, and then I shifted it to the
> drivers. I don't recall the reason, but it was necessary. So I don't
> want this changed.

Oh dear. Why cannot devfs expand the minor part itself?

It looks like all the drivers need to be given a %d, as Ivan suggests. And we
need to audit all uses to make sure nobody is doing printk(driver.name);

I think it would be better to drop the printf control construct from the
names altogether.

-

2002-01-03 16:29:59

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Andrew Morton wrote:
>
> > By looking at tty_io.c:_tty_make_name(), it seems that the TTY
> > subsystem in the Linux 2.4.x kernel series expects driver.name to be
> > in the form "ttyX%d", even if you're not using devfs. I say that
> > because as of now the definition in serial.c for this variable is:
> >
> > #if defined(CONFIG_DEVFS_FS)
> > serial_driver.name = "tts/%d";
> > #else
> > serial_driver.name = "ttyS";
> > #endif
> >
> > , when it seems it should be:
> >
> > #if defined(CONFIG_DEVFS_FS)
> > serial_driver.name = "tts/%d";
> > #else
> > serial_driver.name = "ttyS%d";
> > #endif
>
> I don't think so. Some quick grepping indicates that _all_
> tty drivers currently use the "ttyS" equivalent if !CONFIG_DEVFS.
>
> Instead, it appears that someone broke tty_name(). Here's the
> 2.2 kernel's version:
>
> char *tty_name(struct tty_struct *tty, char *buf)
> {
> if (tty)
> sprintf(buf, "%s%d", tty->driver.name, TTY_NUMBER(tty));
> else
> strcpy(buf, "NULL tty");
> return buf;
> }
>
> And that's much more sensible. The tty has a name associated with
> what it is (eg "ttyS") - correlates with major number, probably.
> And it has an instance number.
>
> Which is cleaner, IMO, than embedding printf control strings
> in the driver name.
>
> --- linux-2.4.18-pre1/drivers/char/tty_io.c Wed Dec 26 11:47:40 2001
> +++ linux-akpm/drivers/char/tty_io.c Wed Jan 2 20:39:53 2002
> @@ -194,7 +194,7 @@ _tty_make_name(struct tty_struct *tty, c
> if (!tty) /* Hmm. NULL pointer. That's fun. */
> strcpy(buf, "NULL tty");
> else
> - sprintf(buf, name,
> + sprintf(buf, "%s%d", name,
> idx + tty->driver.name_base);
>
> return buf;
>
> Does this look (and work) OK to you?

No, because with this implementation you'll break the devfs printk.

We have two options, I guess:

1) Change the drivers to have "ttx/%d" (devfs) and "ttyX%d"
(non-devfs), and leave _tty_make_name() untouched (my original
suggestion).

2) Change the drivers to have "ttx/" (devfs) and "ttyX" (non-devfs)
and change _tty_make_name() as suggested above by Andrew. I don't
know how this would affect devfs though ...

I really don't care which solution is used (although I do prefer
option 2, if possible), but I'm sure that it can't stay as it is
now, because right now it's broken.

So ... Which one is more appropriate?? Any other suggestions??

Later,
--
Ivan Passos -o)
Integration Manager, Cyclades - http://www.cyclades.com /\\
Project Leader, NetLinOS - http://www.netlinos.org _\_V
--------------------------------------------------------------------

2002-01-06 20:12:37

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Andrew Morton writes:
> Richard Gooch wrote:
> >
> > > Instead, it appears that someone broke tty_name(). Here's the
> > > 2.2 kernel's version:
> >
> > That "someone" was me, and I changed it from broken to fixed.
> >
>
> Look at serial.c:
>
> #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
> serial_driver.name = "tts/%d";
> #else
> serial_driver.name = "ttyS";
> #endif
>
> tty_name will just print "ttyS". So the transition for this case
> was fixed->broken.

Why exactly is just "ttyS" broken?

> > No, originally tty_name() did it, and then I shifted it to the
> > drivers. I don't recall the reason, but it was necessary. So I don't
> > want this changed.
>
> Oh dear. Why cannot devfs expand the minor part itself?

Do you mean why devfs can't do it, or do you mean why tty_name() can't
do it? As I said, tty_name() used to do it, but there was some problem
with that.

Regards,

Richard....
Permanent: [email protected]
Current: [email protected]

2002-01-06 20:26:08

by Alan

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

> > Oh dear. Why cannot devfs expand the minor part itself?
>
> Do you mean why devfs can't do it, or do you mean why tty_name() can't
> do it? As I said, tty_name() used to do it, but there was some problem
> with that.

What was the problem ?

2002-01-06 20:34:48

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Alan Cox writes:
> > > Oh dear. Why cannot devfs expand the minor part itself?
> >
> > Do you mean why devfs can't do it, or do you mean why tty_name() can't
> > do it? As I said, tty_name() used to do it, but there was some problem
> > with that.
>
> What was the problem ?

Dunno. Lost in the mists of time, when the world was young.

Regards,

Richard....
Permanent: [email protected]
Current: [email protected]

2002-01-06 21:13:41

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Richard Gooch wrote:
>
> Andrew Morton writes:
> > Richard Gooch wrote:
> > >
> > > > Instead, it appears that someone broke tty_name(). Here's the
> > > > 2.2 kernel's version:
> > >
> > > That "someone" was me, and I changed it from broken to fixed.
> > >
> >
> > Look at serial.c:
> >
> > #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
> > serial_driver.name = "tts/%d";
> > #else
> > serial_driver.name = "ttyS";
> > #endif
> >
> > tty_name will just print "ttyS". So the transition for this case
> > was fixed->broken.
>
> Why exactly is just "ttyS" broken?
>

umm.. Because it doesn't tell the user which serial port the
message pertains to?

Here's a first cut. This is silly, and we don't want to do
it this way. The "/%d" or "%d" concat, and the knowledge of devfs
should be contained in one place. Please suggest something.

net/irda/ircomm/ircomm_tty.c doesn't have a "/" in the name for
the devfs case. Please review that.

--- linux-2.4.18-pre1/net/irda/ircomm/ircomm_tty.c Sun Sep 30 12:26:09 2001
+++ linux-akpm/net/irda/ircomm/ircomm_tty.c Sun Jan 6 12:44:20 2002
@@ -103,7 +103,7 @@ int __init ircomm_tty_init(void)
#ifdef CONFIG_DEVFS_FS
driver.name = "ircomm%d";
#else
- driver.name = "ircomm";
+ driver.name = "ircomm%d";
#endif
driver.major = IRCOMM_TTY_MAJOR;
driver.minor_start = IRCOMM_TTY_MINOR;
--- linux-2.4.18-pre1/drivers/net/wan/sdla_chdlc.c Thu Sep 13 16:04:43 2001
+++ linux-akpm/drivers/net/wan/sdla_chdlc.c Sun Jan 6 13:01:32 2002
@@ -4638,7 +4638,7 @@ int wanpipe_tty_init(sdla_t *card)
memset(&serial_driver, 0, sizeof(struct tty_driver));
serial_driver.magic = TTY_DRIVER_MAGIC;
serial_driver.driver_name = "wanpipe_tty";
- serial_driver.name = "ttyW";
+ serial_driver.name = "ttyW%d";
serial_driver.major = WAN_TTY_MAJOR;
serial_driver.minor_start = WAN_TTY_MINOR;
serial_driver.num = NR_PORTS;
--- linux-2.4.18-pre1/drivers/char/pty.c Fri Dec 21 11:19:13 2001
+++ linux-akpm/drivers/char/pty.c Sun Jan 6 12:47:10 2002
@@ -452,11 +452,7 @@ int __init pty_init(void)
init_waitqueue_head(&ptm_state[i][j].open_wait);

pts_driver[i] = pty_slave_driver;
-#ifdef CONFIG_DEVFS_FS
pts_driver[i].name = "pts/%d";
-#else
- pts_driver[i].name = "pts";
-#endif
pts_driver[i].proc_entry = 0;
pts_driver[i].major = UNIX98_PTY_SLAVE_MAJOR+i;
pts_driver[i].minor_start = 0;
--- linux-2.4.18-pre1/drivers/char/esp.c Thu Nov 22 23:02:57 2001
+++ linux-akpm/drivers/char/esp.c Sun Jan 6 13:02:00 2002
@@ -2547,7 +2547,7 @@ int __init espserial_init(void)

memset(&esp_driver, 0, sizeof(struct tty_driver));
esp_driver.magic = TTY_DRIVER_MAGIC;
- esp_driver.name = "ttyP";
+ esp_driver.name = "ttyP%d";
esp_driver.major = ESP_IN_MAJOR;
esp_driver.minor_start = 0;
esp_driver.num = NR_PORTS;
--- linux-2.4.18-pre1/drivers/char/serial.c Wed Dec 26 11:47:40 2001
+++ linux-akpm/drivers/char/serial.c Sun Jan 6 12:47:56 2002
@@ -5389,7 +5389,7 @@ static int __init rs_init(void)
#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
serial_driver.name = "tts/%d";
#else
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
#endif
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64 + SERIAL_DEV_OFFSET;
--- linux-2.4.18-pre1/drivers/char/cyclades.c Fri Sep 14 14:04:07 2001
+++ linux-akpm/drivers/char/cyclades.c Sun Jan 6 12:48:34 2002
@@ -5496,7 +5496,7 @@ cy_init(void)
memset(&cy_serial_driver, 0, sizeof(struct tty_driver));
cy_serial_driver.magic = TTY_DRIVER_MAGIC;
cy_serial_driver.driver_name = "cyclades";
- cy_serial_driver.name = "ttyC";
+ cy_serial_driver.name = "ttyC%d";
cy_serial_driver.major = CYCLADES_MAJOR;
cy_serial_driver.minor_start = 0;
cy_serial_driver.num = NR_PORTS;
--- linux-2.4.18-pre1/drivers/char/rocket.c Fri Sep 21 10:55:22 2001
+++ linux-akpm/drivers/char/rocket.c Sun Jan 6 12:48:48 2002
@@ -2189,7 +2189,7 @@ int __init rp_init(void)
#ifdef CONFIG_DEVFS_FS
rocket_driver.name = "tts/R%d";
#else
- rocket_driver.name = "ttyR";
+ rocket_driver.name = "ttyR%d";
#endif
rocket_driver.major = TTY_ROCKET_MAJOR;
rocket_driver.minor_start = 0;
--- linux-2.4.18-pre1/drivers/char/istallion.c Mon Nov 5 21:01:11 2001
+++ linux-akpm/drivers/char/istallion.c Sun Jan 6 13:02:33 2002
@@ -171,9 +171,9 @@ static devfs_handle_t devfs_handle;
* all the local structures required by a serial tty driver.
*/
static char *stli_drvtitle = "Stallion Intelligent Multiport Serial Driver";
-static char *stli_drvname = "istallion";
+static char *stli_drvname = "istallion%d";
static char *stli_drvversion = "5.6.0";
-static char *stli_serialname = "ttyE";
+static char *stli_serialname = "ttyE%d";
static char *stli_calloutname = "cue";

static struct tty_driver stli_serial;
--- linux-2.4.18-pre1/drivers/char/pcxx.c Thu Sep 13 15:21:32 2001
+++ linux-akpm/drivers/char/pcxx.c Sun Jan 6 12:49:49 2002
@@ -1229,7 +1229,7 @@ int __init pcxe_init(void)

memset(&pcxe_driver, 0, sizeof(struct tty_driver));
pcxe_driver.magic = TTY_DRIVER_MAGIC;
- pcxe_driver.name = "ttyD";
+ pcxe_driver.name = "ttyD%d";
pcxe_driver.major = DIGI_MAJOR;
pcxe_driver.minor_start = 0;

--- linux-2.4.18-pre1/drivers/char/sh-sci.c Mon Oct 15 13:36:48 2001
+++ linux-akpm/drivers/char/sh-sci.c Sun Jan 6 13:02:56 2002
@@ -1025,7 +1025,7 @@ static int sci_init_drivers(void)
#ifdef CONFIG_DEVFS_FS
sci_driver.name = "ttsc/%d";
#else
- sci_driver.name = "ttySC";
+ sci_driver.name = "ttySC%d";
#endif
sci_driver.major = SCI_MAJOR;
sci_driver.minor_start = SCI_MINOR_START;
@@ -1064,7 +1064,7 @@ static int sci_init_drivers(void)
#ifdef CONFIG_DEVFS_FS
sci_callout_driver.name = "cusc/%d";
#else
- sci_callout_driver.name = "cusc";
+ sci_callout_driver.name = "cusc%d";
#endif
sci_callout_driver.major = SCI_MAJOR+1;
sci_callout_driver.subtype = SERIAL_TYPE_CALLOUT;
--- linux-2.4.18-pre1/drivers/char/riscom8.c Thu Sep 13 15:21:32 2001
+++ linux-akpm/drivers/char/riscom8.c Sun Jan 6 12:50:08 2002
@@ -1755,7 +1755,7 @@ static inline int rc_init_drivers(void)
memset(IRQ_to_board, 0, sizeof(IRQ_to_board));
memset(&riscom_driver, 0, sizeof(riscom_driver));
riscom_driver.magic = TTY_DRIVER_MAGIC;
- riscom_driver.name = "ttyL";
+ riscom_driver.name = "ttyL%d";
riscom_driver.major = RISCOM8_NORMAL_MAJOR;
riscom_driver.num = RC_NBOARD * RC_NPORT;
riscom_driver.type = TTY_DRIVER_TYPE_SERIAL;
--- linux-2.4.18-pre1/drivers/char/specialix.c Thu Nov 22 23:02:57 2001
+++ linux-akpm/drivers/char/specialix.c Sun Jan 6 12:50:17 2002
@@ -2233,7 +2233,7 @@ static int sx_init_drivers(void)
init_bh(SPECIALIX_BH, do_specialix_bh);
memset(&specialix_driver, 0, sizeof(specialix_driver));
specialix_driver.magic = TTY_DRIVER_MAGIC;
- specialix_driver.name = "ttyW";
+ specialix_driver.name = "ttyW%d";
specialix_driver.major = SPECIALIX_NORMAL_MAJOR;
specialix_driver.num = SX_NBOARD * SX_NPORT;
specialix_driver.type = TTY_DRIVER_TYPE_SERIAL;
--- linux-2.4.18-pre1/drivers/char/epca.c Fri Oct 12 13:48:42 2001
+++ linux-akpm/drivers/char/epca.c Sun Jan 6 12:50:27 2002
@@ -1718,7 +1718,7 @@ int __init pc_init(void)
memset(&pc_info, 0, sizeof(struct tty_driver));

pc_driver.magic = TTY_DRIVER_MAGIC;
- pc_driver.name = "ttyD";
+ pc_driver.name = "ttyD%d";
pc_driver.major = DIGI_MAJOR;
pc_driver.minor_start = 0;
pc_driver.num = MAX_ALLOC;
--- linux-2.4.18-pre1/drivers/char/sx.c Thu Nov 22 23:02:57 2001
+++ linux-akpm/drivers/char/sx.c Sun Jan 6 12:50:38 2002
@@ -2222,7 +2222,7 @@ static int sx_init_drivers(void)
memset(&sx_driver, 0, sizeof(sx_driver));
sx_driver.magic = TTY_DRIVER_MAGIC;
sx_driver.driver_name = "specialix_sx";
- sx_driver.name = "ttyX";
+ sx_driver.name = "ttyX%d";
sx_driver.major = SX_NORMAL_MAJOR;
sx_driver.num = sx_nports;
sx_driver.type = TTY_DRIVER_TYPE_SERIAL;
--- linux-2.4.18-pre1/drivers/char/serial_amba.c Sun Sep 16 21:23:14 2001
+++ linux-akpm/drivers/char/serial_amba.c Sun Jan 6 12:51:16 2002
@@ -1776,7 +1776,7 @@ int __init ambauart_init(void)

ambanormal_driver.magic = TTY_DRIVER_MAGIC;
ambanormal_driver.driver_name = "serial_amba";
- ambanormal_driver.name = SERIAL_AMBA_NAME;
+ ambanormal_driver.name = SERIAL_AMBA_NAME "%d";
ambanormal_driver.major = SERIAL_AMBA_MAJOR;
ambanormal_driver.minor_start = SERIAL_AMBA_MINOR;
ambanormal_driver.num = SERIAL_AMBA_NR;
--- linux-2.4.18-pre1/drivers/char/dz.c Sun Sep 9 10:43:02 2001
+++ linux-akpm/drivers/char/dz.c Sun Jan 6 13:03:32 2002
@@ -1338,7 +1338,7 @@ int __init dz_init(void)
memset(&serial_driver, 0, sizeof(struct tty_driver));
serial_driver.magic = TTY_DRIVER_MAGIC;
#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
#else
serial_driver.name = "tts/%d";
#endif
@@ -1379,7 +1379,7 @@ int __init dz_init(void)
*/
callout_driver = serial_driver;
#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
- callout_driver.name = "cua";
+ callout_driver.name = "cua%d";
#else
callout_driver.name = "cua/%d";
#endif
--- linux-2.4.18-pre1/drivers/char/isicom.c Thu Nov 22 23:02:57 2001
+++ linux-akpm/drivers/char/isicom.c Sun Jan 6 12:51:37 2002
@@ -1718,7 +1718,7 @@ static int register_drivers(void)
/* tty driver structure initialization */
memset(&isicom_normal, 0, sizeof(struct tty_driver));
isicom_normal.magic = TTY_DRIVER_MAGIC;
- isicom_normal.name = "ttyM";
+ isicom_normal.name = "ttyM%d";
isicom_normal.major = ISICOM_NMAJOR;
isicom_normal.minor_start = 0;
isicom_normal.num = PORT_COUNT;
--- linux-2.4.18-pre1/drivers/char/synclink.c Fri Dec 21 11:19:13 2001
+++ linux-akpm/drivers/char/synclink.c Sun Jan 6 12:51:45 2002
@@ -4587,7 +4587,7 @@ int mgsl_init_tty()
memset(&serial_driver, 0, sizeof(struct tty_driver));
serial_driver.magic = TTY_DRIVER_MAGIC;
serial_driver.driver_name = "synclink";
- serial_driver.name = "ttySL";
+ serial_driver.name = "ttySL%d";
serial_driver.major = ttymajor;
serial_driver.minor_start = 64;
serial_driver.num = mgsl_device_count;
--- linux-2.4.18-pre1/drivers/char/mxser.c Mon Nov 5 21:01:11 2001
+++ linux-akpm/drivers/char/mxser.c Sun Jan 6 12:51:53 2002
@@ -523,7 +523,7 @@ int mxser_init(void)
* major number and the subtype code.
*/
mxvar_cdriver = mxvar_sdriver;
- mxvar_cdriver.name = "cum";
+ mxvar_cdriver.name = "cum%d";
mxvar_cdriver.major = calloutmajor;
mxvar_cdriver.subtype = SERIAL_TYPE_CALLOUT;

--- linux-2.4.18-pre1/drivers/char/serial167.c Sun Sep 16 21:23:07 2001
+++ linux-akpm/drivers/char/serial167.c Sun Jan 6 12:51:59 2002
@@ -2395,7 +2395,7 @@ scrn[1] = '\0';

memset(&cy_serial_driver, 0, sizeof(struct tty_driver));
cy_serial_driver.magic = TTY_DRIVER_MAGIC;
- cy_serial_driver.name = "ttyS";
+ cy_serial_driver.name = "ttyS%d";
cy_serial_driver.major = TTY_MAJOR;
cy_serial_driver.minor_start = 64;
cy_serial_driver.num = NR_PORTS;
--- linux-2.4.18-pre1/drivers/char/ip2main.c Mon Nov 5 21:01:11 2001
+++ linux-akpm/drivers/char/ip2main.c Sun Jan 6 12:52:46 2002
@@ -235,7 +235,7 @@ static char *pcDriver_name = "ip2";
static char *pcTty = "tts/F%d";
static char *pcCallout = "cua/F%d";
#else
-static char *pcTty = "ttyF";
+static char *pcTty = "ttyF%d";
static char *pcCallout = "cuf";
#endif
static char *pcIpl = "ip2ipl";
--- linux-2.4.18-pre1/drivers/char/vme_scc.c Sun Sep 16 21:22:50 2001
+++ linux-akpm/drivers/char/vme_scc.c Sun Jan 6 12:52:57 2002
@@ -131,7 +131,7 @@ static int scc_init_drivers(void)
memset(&scc_driver, 0, sizeof(scc_driver));
scc_driver.magic = TTY_DRIVER_MAGIC;
scc_driver.driver_name = "scc";
- scc_driver.name = "ttyS";
+ scc_driver.name = "ttyS%d";
scc_driver.major = TTY_MAJOR;
scc_driver.minor_start = SCC_MINOR_BASE;
scc_driver.num = 2;
--- linux-2.4.18-pre1/drivers/char/stallion.c Fri Sep 21 10:55:23 2001
+++ linux-akpm/drivers/char/stallion.c Sun Jan 6 12:53:17 2002
@@ -143,7 +143,7 @@ static char *stl_drvversion = "5.6.0";
static char *stl_serialname = "tts/E%d";
static char *stl_calloutname = "cua/E%d";
#else
-static char *stl_serialname = "ttyE";
+static char *stl_serialname = "ttyE%d";
static char *stl_calloutname = "cue";
#endif

--- linux-2.4.18-pre1/drivers/char/rio/rio_linux.c Mon Nov 5 21:01:11 2001
+++ linux-akpm/drivers/char/rio/rio_linux.c Sun Jan 6 12:53:40 2002
@@ -912,7 +912,7 @@ static int rio_init_drivers(void)
memset(&rio_driver, 0, sizeof(rio_driver));
rio_driver.magic = TTY_DRIVER_MAGIC;
rio_driver.driver_name = "specialix_rio";
- rio_driver.name = "ttySR";
+ rio_driver.name = "ttySR%d";
rio_driver.major = RIO_NORMAL_MAJOR0;
rio_driver.num = 256;
rio_driver.type = TTY_DRIVER_TYPE_SERIAL;
--- linux-2.4.18-pre1/drivers/char/moxa.c Mon Nov 5 21:01:11 2001
+++ linux-akpm/drivers/char/moxa.c Sun Jan 6 12:53:51 2002
@@ -344,7 +344,7 @@ int moxa_init(void)
memset(&moxaDriver, 0, sizeof(struct tty_driver));
memset(&moxaCallout, 0, sizeof(struct tty_driver));
moxaDriver.magic = TTY_DRIVER_MAGIC;
- moxaDriver.name = "ttya";
+ moxaDriver.name = "ttya%d";
moxaDriver.major = ttymajor;
moxaDriver.minor_start = 0;
moxaDriver.num = MAX_PORTS + 1;
--- linux-2.4.18-pre1/drivers/char/serial_21285.c Thu Sep 13 15:21:32 2001
+++ linux-akpm/drivers/char/serial_21285.c Sun Jan 6 12:54:09 2002
@@ -299,7 +299,7 @@ static int __init rs285_init(void)

rs285_driver.magic = TTY_DRIVER_MAGIC;
rs285_driver.driver_name = "serial_21285";
- rs285_driver.name = SERIAL_21285_NAME;
+ rs285_driver.name = SERIAL_21285_NAME "%d";
rs285_driver.major = SERIAL_21285_MAJOR;
rs285_driver.minor_start = SERIAL_21285_MINOR;
rs285_driver.num = 1;
--- linux-2.4.18-pre1/drivers/char/amiserial.c Sun Sep 16 21:22:56 2001
+++ linux-akpm/drivers/char/amiserial.c Sun Jan 6 12:54:20 2002
@@ -2129,7 +2129,7 @@ static int __init rs_init(void)
memset(&serial_driver, 0, sizeof(struct tty_driver));
serial_driver.magic = TTY_DRIVER_MAGIC;
serial_driver.driver_name = "amiserial";
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64;
serial_driver.num = 1;
--- linux-2.4.18-pre1/drivers/char/ser_a2232.c Thu Sep 13 15:21:32 2001
+++ linux-akpm/drivers/char/ser_a2232.c Sun Jan 6 12:54:27 2002
@@ -716,7 +716,7 @@ static int a2232_init_drivers(void)
memset(&a2232_driver, 0, sizeof(a2232_driver));
a2232_driver.magic = TTY_DRIVER_MAGIC;
a2232_driver.driver_name = "commodore_a2232";
- a2232_driver.name = "ttyY";
+ a2232_driver.name = "ttyY%d";
a2232_driver.major = A2232_NORMAL_MAJOR;
a2232_driver.num = NUMLINES * nr_a2232;
a2232_driver.type = TTY_DRIVER_TYPE_SERIAL;
--- linux-2.4.18-pre1/drivers/char/serial_tx3912.c Thu Nov 22 23:02:57 2001
+++ linux-akpm/drivers/char/serial_tx3912.c Sun Jan 6 12:54:35 2002
@@ -841,7 +841,7 @@ static int rs_init_drivers(void)
memset(&rs_driver, 0, sizeof(rs_driver));
rs_driver.magic = TTY_DRIVER_MAGIC;
rs_driver.driver_name = "serial";
- rs_driver.name = "ttyS";
+ rs_driver.name = "ttyS%d";
rs_driver.major = TTY_MAJOR;
rs_driver.minor_start = 64;
rs_driver.num = TX3912_UART_NPORTS;
--- linux-2.4.18-pre1/drivers/isdn/isdn_tty.c Fri Dec 21 11:19:13 2001
+++ linux-akpm/drivers/isdn/isdn_tty.c Sun Jan 6 12:54:52 2002
@@ -44,7 +44,7 @@ static int isdn_tty_countDLE(unsigned ch
static char *isdn_ttyname_ttyI = "isdn/ttyI%d";
static char *isdn_ttyname_cui = "isdn/cui%d";
#else
-static char *isdn_ttyname_ttyI = "ttyI";
+static char *isdn_ttyname_ttyI = "ttyI%d";
static char *isdn_ttyname_cui = "cui";
#endif

--- linux-2.4.18-pre1/drivers/sbus/char/zs.c Mon Nov 5 21:01:11 2001
+++ linux-akpm/drivers/sbus/char/zs.c Sun Jan 6 12:55:13 2002
@@ -2412,7 +2412,7 @@ int __init zs_init(void)
#ifdef CONFIG_DEVFS_FS
serial_driver.name = "tts/%d";
#else
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
#endif
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64;
--- linux-2.4.18-pre1/drivers/sbus/char/sab82532.c Wed Oct 17 14:16:39 2001
+++ linux-akpm/drivers/sbus/char/sab82532.c Sun Jan 6 12:55:22 2002
@@ -2240,7 +2240,7 @@ int __init sab82532_init(void)
#ifdef CONFIG_DEVFS_FS
serial_driver.name = "tts/%d";
#else
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
#endif
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64 + su_num_ports;
--- linux-2.4.18-pre1/drivers/sbus/char/su.c Thu Nov 22 23:02:58 2001
+++ linux-akpm/drivers/sbus/char/su.c Sun Jan 6 12:55:31 2002
@@ -2491,7 +2491,7 @@ int __init su_serial_init(void)
#ifdef CONFIG_DEVFS_FS
serial_driver.name = "tts/%d";
#else
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
#endif
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64;
--- linux-2.4.18-pre1/drivers/sbus/char/aurora.c Mon Nov 5 21:01:11 2001
+++ linux-akpm/drivers/sbus/char/aurora.c Sun Jan 6 12:55:38 2002
@@ -2313,7 +2313,7 @@ static int aurora_init_drivers(void)
/* memset(IRQ_to_board, 0, sizeof(IRQ_to_board));*/
memset(&aurora_driver, 0, sizeof(aurora_driver));
aurora_driver.magic = TTY_DRIVER_MAGIC;
- aurora_driver.name = "ttyA";
+ aurora_driver.name = "ttyA%d";
aurora_driver.major = AURORA_MAJOR;
aurora_driver.num = AURORA_TNPORTS;
aurora_driver.type = TTY_DRIVER_TYPE_SERIAL;
--- linux-2.4.18-pre1/drivers/macintosh/macserial.c Wed Dec 26 11:47:40 2001
+++ linux-akpm/drivers/macintosh/macserial.c Sun Jan 6 12:55:43 2002
@@ -2623,7 +2623,7 @@ no_dma:
#ifdef CONFIG_DEVFS_FS
callout_driver.name = "cua/%d";
#else
- callout_driver.name = "cua";
+ callout_driver.name = "cua%d";
#endif /* CONFIG_DEVFS_FS */
callout_driver.major = TTYAUX_MAJOR;
callout_driver.subtype = SERIAL_TYPE_CALLOUT;
--- linux-2.4.18-pre1/drivers/sgi/char/sgiserial.c Mon Aug 27 08:56:31 2001
+++ linux-akpm/drivers/sgi/char/sgiserial.c Sun Jan 6 12:55:52 2002
@@ -1911,7 +1911,7 @@ int rs_init(void)
* major number and the subtype code.
*/
callout_driver = serial_driver;
- callout_driver.name = "cua";
+ callout_driver.name = "cua%d";
callout_driver.major = TTYAUX_MAJOR;
callout_driver.subtype = SERIAL_TYPE_CALLOUT;

--- linux-2.4.18-pre1/drivers/tc/zs.c Mon Aug 27 08:56:31 2001
+++ linux-akpm/drivers/tc/zs.c Sun Jan 6 12:56:12 2002
@@ -1877,7 +1877,7 @@ int __init zs_init(void)
#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
serial_driver.name = "tts/%d";
#else
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
#endif
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64;
--- linux-2.4.18-pre1/drivers/s390/char/con3215.c Wed Jul 25 14:12:02 2001
+++ linux-akpm/drivers/s390/char/con3215.c Sun Jan 6 12:56:20 2002
@@ -1129,7 +1129,7 @@ void __init tty3215_init(void)
memset(&tty3215_driver, 0, sizeof(struct tty_driver));
tty3215_driver.magic = TTY_DRIVER_MAGIC;
tty3215_driver.driver_name = "tty3215";
- tty3215_driver.name = "ttyS";
+ tty3215_driver.name = "ttyS%d";
tty3215_driver.name_base = 0;
tty3215_driver.major = TTY_MAJOR;
tty3215_driver.minor_start = 64;
--- linux-2.4.18-pre1/drivers/s390/char/hwc_tty.c Wed Jul 25 14:12:02 2001
+++ linux-akpm/drivers/s390/char/hwc_tty.c Sun Jan 6 12:56:29 2002
@@ -227,7 +227,7 @@ hwc_tty_init (void)
memset (&hwc_tty_data, 0, sizeof (hwc_tty_data_struct));
hwc_tty_driver.magic = TTY_DRIVER_MAGIC;
hwc_tty_driver.driver_name = "tty_hwc";
- hwc_tty_driver.name = "ttyS";
+ hwc_tty_driver.name = "ttyS%d";
hwc_tty_driver.name_base = 0;
hwc_tty_driver.major = TTY_MAJOR;
hwc_tty_driver.minor_start = 64;
--- linux-2.4.18-pre1/drivers/s390/net/ctctty.c Wed Jul 25 14:12:02 2001
+++ linux-akpm/drivers/s390/net/ctctty.c Sun Jan 6 12:57:15 2002
@@ -111,7 +111,7 @@ static ctc_tty_driver *driver;
#ifdef CONFIG_DEVFS_FS
static char *ctc_ttyname = "ctc/" CTC_TTY_NAME "%d";
#else
-static char *ctc_ttyname = CTC_TTY_NAME;
+static char *ctc_ttyname = CTC_TTY_NAME "%d";
#endif

char *ctc_tty_revision = "$Revision: 1.1.2.1 $";
--- linux-2.4.18-pre1/arch/mips/baget/vacserial.c Sun Sep 9 10:43:01 2001
+++ linux-akpm/arch/mips/baget/vacserial.c Sun Jan 6 12:57:26 2002
@@ -2359,7 +2359,7 @@ int __init rs_init(void)
memset(&serial_driver, 0, sizeof(struct tty_driver));
serial_driver.magic = TTY_DRIVER_MAGIC;
serial_driver.driver_name = "serial";
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64;
serial_driver.num = NR_PORTS;
--- linux-2.4.18-pre1/arch/mips/au1000/common/serial.c Fri Oct 5 12:06:51 2001
+++ linux-akpm/arch/mips/au1000/common/serial.c Sun Jan 6 12:57:34 2002
@@ -2635,7 +2635,7 @@ static int __init rs_init(void)
#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
callout_driver.name = "cua/%d";
#else
- callout_driver.name = "cua";
+ callout_driver.name = "cua%d";
#endif
callout_driver.major = TTYAUX_MAJOR;
callout_driver.subtype = SERIAL_TYPE_CALLOUT;
--- linux-2.4.18-pre1/arch/ppc/8xx_io/uart.c Wed Dec 26 11:47:40 2001
+++ linux-akpm/arch/ppc/8xx_io/uart.c Sun Jan 6 12:57:42 2002
@@ -2532,7 +2532,7 @@ int __init rs_8xx_init(void)
#ifdef CONFIG_DEVFS_FS
serial_driver.name = "tts/%d";
#else
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
#endif
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64;
--- linux-2.4.18-pre1/arch/ppc/8260_io/uart.c Wed Dec 26 11:47:40 2001
+++ linux-akpm/arch/ppc/8260_io/uart.c Sun Jan 6 12:57:52 2002
@@ -2328,7 +2328,7 @@ int __init rs_8xx_init(void)
#ifdef CONFIG_DEVFS_FS
serial_driver.name = "tts/%d";
#else
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
#endif
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64;
--- linux-2.4.18-pre1/arch/cris/drivers/serial.c Thu Nov 22 23:02:57 2001
+++ linux-akpm/arch/cris/drivers/serial.c Sun Jan 6 12:58:03 2002
@@ -3461,7 +3461,7 @@ rs_init(void)
#if (LINUX_VERSION_CODE > 0x20100)
serial_driver.driver_name = "serial";
#endif
- serial_driver.name = "ttyS";
+ serial_driver.name = "ttyS%d";
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64;
serial_driver.num = NR_PORTS; /* etrax100 has 4 serial ports */

2002-01-07 06:37:25

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Andrew Morton writes:
> Richard Gooch wrote:
> >
> > Andrew Morton writes:
> > > Richard Gooch wrote:
> > > >
> > > > > Instead, it appears that someone broke tty_name(). Here's the
> > > > > 2.2 kernel's version:
> > > >
> > > > That "someone" was me, and I changed it from broken to fixed.
> > > >
> > >
> > > Look at serial.c:
> > >
> > > #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
> > > serial_driver.name = "tts/%d";
> > > #else
> > > serial_driver.name = "ttyS";
> > > #endif
> > >
> > > tty_name will just print "ttyS". So the transition for this case
> > > was fixed->broken.
> >
> > Why exactly is just "ttyS" broken?
>
> umm.. Because it doesn't tell the user which serial port the
> message pertains to?

Exactly where is it broken? I look at my dmesg output and things look
fine.

Regards,

Richard....
Permanent: [email protected]
Current: [email protected]

2002-01-07 07:26:00

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Richard Gooch wrote:
>
> > > Why exactly is just "ttyS" broken?
> >
> > umm.. Because it doesn't tell the user which serial port the
> > message pertains to?
>
> Exactly where is it broken? I look at my dmesg output and things look
> fine.
>

Try disabling devfs.

At the head-of-thread, Ivan said:

> This was spotted by a Cyclades customer who was getting overrun msgs
> as:
>
> ttyC: 1 input overrun(s)
>
> After he changed the driver.name to be "ttyC%d", he started to get
> properly formatted msgs, such as:
>
> ttyC39: 1 input overrun(s)
>
> This problem would happen on any msg that used the function
> tty_name() to get the TTY name, and after the change the problem
> disappeared completely.

-

2002-01-08 05:09:19

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

[ tty driver name breakage ]

Richard, can we please get this wrapped up?

My preferred approach is to change the driver naming scheme
so that we don't have to put printf control-strings everywhere.
We can remove a number of ifdefs that way.

So for serial.c:

--- linux-2.4.18-pre2/drivers/char/tty_io.c Mon Jan 7 16:48:02 2002
+++ linux-akpm/drivers/char/tty_io.c Mon Jan 7 20:56:38 2002
@@ -193,10 +193,13 @@ _tty_make_name(struct tty_struct *tty, c

if (!tty) /* Hmm. NULL pointer. That's fun. */
strcpy(buf, "NULL tty");
- else
- sprintf(buf, name,
- idx + tty->driver.name_base);
-
+ else {
+#ifdef CONFIG_DEVFS_FS
+ sprintf(buf, "%s/%d", name, idx + tty->driver.name_base);
+#else
+ sprintf(buf, "%s%d", name, idx + tty->driver.name_base);
+#endif
+ }
return buf;
}

--- linux-2.4.18-pre2/drivers/char/serial.c Mon Jan 7 16:48:02 2002
+++ linux-akpm/drivers/char/serial.c Mon Jan 7 20:58:09 2002
@@ -5387,7 +5387,7 @@ static int __init rs_init(void)
serial_driver.driver_name = "serial";
#endif
#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
- serial_driver.name = "tts/%d";
+ serial_driver.name = "tts";
#else
serial_driver.name = "ttyS";
#endif

2002-01-08 06:16:28

by David Weinehall

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

On Mon, Jan 07, 2002 at 09:03:35PM -0800, Andrew Morton wrote:
> [ tty driver name breakage ]
>
> Richard, can we please get this wrapped up?
>
> My preferred approach is to change the driver naming scheme
> so that we don't have to put printf control-strings everywhere.
> We can remove a number of ifdefs that way.

Wouldn't it be cleaner to have:

#ifdef CONFIG_DEVFS_FS
serial_driver.name = "tts/";
#else
serial_driver.name = "tts";
#endif

and

sprintf("buf, "%s%d", name, idx + tty->driver.name_base);

respectively?!

/David

> So for serial.c:
>
> --- linux-2.4.18-pre2/drivers/char/tty_io.c Mon Jan 7 16:48:02 2002
> +++ linux-akpm/drivers/char/tty_io.c Mon Jan 7 20:56:38 2002
> @@ -193,10 +193,13 @@ _tty_make_name(struct tty_struct *tty, c
>
> if (!tty) /* Hmm. NULL pointer. That's fun. */
> strcpy(buf, "NULL tty");
> - else
> - sprintf(buf, name,
> - idx + tty->driver.name_base);
> -
> + else {
> +#ifdef CONFIG_DEVFS_FS
> + sprintf(buf, "%s/%d", name, idx + tty->driver.name_base);
> +#else
> + sprintf(buf, "%s%d", name, idx + tty->driver.name_base);
> +#endif
> + }
> return buf;
> }
>
> --- linux-2.4.18-pre2/drivers/char/serial.c Mon Jan 7 16:48:02 2002
> +++ linux-akpm/drivers/char/serial.c Mon Jan 7 20:58:09 2002
> @@ -5387,7 +5387,7 @@ static int __init rs_init(void)
> serial_driver.driver_name = "serial";
> #endif
> #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
> - serial_driver.name = "tts/%d";
> + serial_driver.name = "tts";
> #else
> serial_driver.name = "ttyS";
> #endif

_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </

2002-01-08 06:28:51

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

David Weinehall wrote:
>
> On Mon, Jan 07, 2002 at 09:03:35PM -0800, Andrew Morton wrote:
> > [ tty driver name breakage ]
> >
> > Richard, can we please get this wrapped up?
> >
> > My preferred approach is to change the driver naming scheme
> > so that we don't have to put printf control-strings everywhere.
> > We can remove a number of ifdefs that way.
>
> Wouldn't it be cleaner to have:
>
> #ifdef CONFIG_DEVFS_FS
> serial_driver.name = "tts/";
> #else
> serial_driver.name = "tts";
> #endif
>
> and
>
> sprintf("buf, "%s%d", name, idx + tty->driver.name_base);
>
> respectively?!
>

Well, with the scheme I proposed most drivers won't need the
ifdef. It'll just be:

serial_driver.name = "cua";

With devfs enabled that expands to cua/42. Without devfs it expands
to cua42.

Seems that some drivers have had their name changed when used under
devfs (tts/%d versus ttyS%d). But a lot have not.

-

2002-01-08 18:44:55

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Andrew Morton wrote:
>
> Richard, can we please get this wrapped up?
>
> My preferred approach is to change the driver naming scheme
> so that we don't have to put printf control-strings everywhere.
> We can remove a number of ifdefs that way.
>
> So for serial.c:
>
> --- linux-2.4.18-pre2/drivers/char/tty_io.c Mon Jan 7 16:48:02 2002
> +++ linux-akpm/drivers/char/tty_io.c Mon Jan 7 20:56:38 2002
> @@ -193,10 +193,13 @@ _tty_make_name(struct tty_struct *tty, c
>
> if (!tty) /* Hmm. NULL pointer. That's fun. */
> strcpy(buf, "NULL tty");
> - else
> - sprintf(buf, name,
> - idx + tty->driver.name_base);
> -
> + else {
> +#ifdef CONFIG_DEVFS_FS
> + sprintf(buf, "%s/%d", name, idx + tty->driver.name_base);
> +#else
> + sprintf(buf, "%s%d", name, idx + tty->driver.name_base);
> +#endif
> + }
> return buf;
> }
>
> --- linux-2.4.18-pre2/drivers/char/serial.c Mon Jan 7 16:48:02 2002
> +++ linux-akpm/drivers/char/serial.c Mon Jan 7 20:58:09 2002
> @@ -5387,7 +5387,7 @@ static int __init rs_init(void)
> serial_driver.driver_name = "serial";
> #endif
> #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
> - serial_driver.name = "tts/%d";
> + serial_driver.name = "tts";
> #else
> serial_driver.name = "ttyS";
> #endif

This doesn't cover all the drivers, because the definition for devfs
is that the standard serial "translates" 'ttyS' to 'tts/', and other
serial drivers "translate" 'ttyN' (where 'N' can be several
different letters -- e.g. 'C' for Cyclades, 'R' for Comtrol, 'X' for
Specialix, 'D' for Digi, etc.) to 'tts/N' (so that standard serial
and other serial devices can share the same devfs directory).

So, I believe the best way to solve this would be:

drivers/char/tty_io.c:
@@ -193,10 +193,13 @@ _tty_make_name(struct tty_struct *tty, c

if (!tty) /* Hmm. NULL pointer. That's fun. */
strcpy(buf, "NULL tty");
else
- sprintf(buf, name,
- idx + tty->driver.name_base);
+ sprintf(buf, "%s%d", name, idx + tty->driver.name_base);

return buf;
}

drivers/char/serial.c:
@@ -5387,7 +5387,7 @@ static int __init rs_init(void)
serial_driver.driver_name = "serial";
#endif
#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
- serial_driver.name = "tts/%d";
+ serial_driver.name = "tts/";
#else
serial_driver.name = "ttyS";
#endif

And then, for instance, for the Cyclades driver, we'd use:

#ifdef CONFIG_DEVFS_FS
cy_serial_driver.name = "tts/C";
#else
cy_serial_driver.name = "ttyC";
#endif

, and let's not forget the callout devices (which follow a similar
rule):

#ifdef CONFIG_DEVFS_FS
cy_callout_driver.name = "cua/C";
#else
cy_callout_driver.name = "cub";
#endif

This would apply for other drivers as well, just replacing the 'C'
by the proper letter.

So, what do you think?!?!?

Later,
--
Ivan Passos -o)
Integration Manager, Cyclades - http://www.cyclades.com /\\
Project Leader, NetLinOS - http://www.netlinos.org _\_V
--------------------------------------------------------------------

2002-01-08 18:51:15

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Andrew Morton wrote:
>
> Well, with the scheme I proposed most drivers won't need the
> ifdef. It'll just be:
>
> serial_driver.name = "cua";
>
> With devfs enabled that expands to cua/42. Without devfs it expands
> to cua42.

Check my previous msg. Actually that won't work for other drivers
other than serial.c, that's why we should use the scheme I suggested
on that msg.

Hmmmm, I just thought about something that might be a problem with
this change. I believe Richard Gooch is the right person to tell us
whether this is a problem or not.

We're just talking about print msgs in tty_io.c (and the scheme I
suggested -- i.e. to use 'tts/X' for devfs and 'ttyX' for non-devfs
and have "%s%d" in tty_io.c's printk call -- does cover all driver in
that aspect), but I'm not sure whether devfs uses the driver.name
definition for something else. If that's the case, then devfs would
need to be updated as well to comply with the new driver.name
definition.

Richard, is this a problem or not?!?!

Later,
--
Ivan Passos -o)
Integration Manager, Cyclades - http://www.cyclades.com /\\
Project Leader, NetLinOS - http://www.netlinos.org _\_V
--------------------------------------------------------------------

2002-01-08 21:59:36

by Michael H. Warfield

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

On Mon, Jan 07, 2002 at 10:23:04PM -0800, Andrew Morton wrote:
> David Weinehall wrote:
> >
> > On Mon, Jan 07, 2002 at 09:03:35PM -0800, Andrew Morton wrote:
> > > [ tty driver name breakage ]
> > >
> > > Richard, can we please get this wrapped up?
> > >
> > > My preferred approach is to change the driver naming scheme
> > > so that we don't have to put printf control-strings everywhere.
> > > We can remove a number of ifdefs that way.
> >
> > Wouldn't it be cleaner to have:
> >
> > #ifdef CONFIG_DEVFS_FS
> > serial_driver.name = "tts/";
> > #else
> > serial_driver.name = "tts";
> > #endif
> >
> > and
> >
> > sprintf("buf, "%s%d", name, idx + tty->driver.name_base);
> >
> > respectively?!
> >

> Well, with the scheme I proposed most drivers won't need the
> ifdef. It'll just be:

> serial_driver.name = "cua";

> With devfs enabled that expands to cua/42. Without devfs it expands
> to cua42.

No.

We've been over this in several lists and there are more
issues here. The Computone driver is ttyF%d / tts/F%d cuf%d / cua/F%d.
If I understand your convention (and maybe I do not) then the cuf
driver would be what? Expanded to cuf/42 with devfs and cuf42 without?
That's what it use to be and that created a problem in userland. The
trouble there is the problem with conventional lock files under
/var/lock which only use the base name of the device name so cua/42
and cuf/42 both have the same lock file of /var/lock/LCK..42 and
would collide. Yes we could ALSO change ALL the user space applications
using locks, but I just got done changing the Computone driver to conform
to the non-conflicting convention that had been agreed to. This also
impacts the USB ACM driver and it's devices and lock files.

Unfortunately, the basenames need to be non-conflicting in flat
name space due the the indeterminant pile of applications which are going
to require non-conflicing lock files under a convention that days back to
before Linux or even Taylor UUCP (HDB UUCP used a similar locking scheme).
That includes pppd, slip, uucp, minicom, cu, ecu, tip, mgetty, etc, etc...

> Seems that some drivers have had their name changed when used under
> devfs (tts/%d versus ttyS%d). But a lot have not.

Other drivers which are not under ttyS%d don't make to tts/%d.
As things stand right now, ttyF%d maps to tts/F%d. It use to be mapped
under ttf/%d but this created a lock file conflict with the tts/%d and
usb/acm/%d devices and had to be changed.

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

Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!

2002-01-08 22:17:36

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

"Michael H. Warfield" wrote:
>
> The trouble there is the problem with conventional lock files under
> /var/lock which only use the base name of the device name so cua/42
> and cuf/42 both have the same lock file of /var/lock/LCK..42 and
> would collide.

OK, thanks. So it looks like we stick with

http://www.zip.com.au/~akpm/linux/2.4/2.4.18-pre2/tty_name.patch

Which just puts %d's at the end of all the device names in the
non-devfs case.

I'll have another go at that patch, check for missed drivers,
then send it out again. OK?

2002-01-08 23:30:51

[permalink] [raw]

Subject: Re: Serial Driver Name Question (kernels 2.4.x)

Andrew Morton wrote:
>
> "Michael H. Warfield" wrote:
> >
> > The trouble there is the problem with conventional lock files under
> > /var/lock which only use the base name of the device name so cua/42
> > and cuf/42 both have the same lock file of /var/lock/LCK..42 and
> > would collide.
>
> OK, thanks. So it looks like we stick with
>
> http://www.zip.com.au/~akpm/linux/2.4/2.4.18-pre2/tty_name.patch
>
> Which just puts %d's at the end of all the device names in the
> non-devfs case.
>
> I'll have another go at that patch, check for missed drivers,
> then send it out again. OK?

OK, just two comments:
- As you'll have to patch all drivers anyway, in case Richard Gooch
doesn't have a problem with this suggestion, I'd suggest you patch
the kernel as follows:

(1) drivers/char/tty_io.c
---------------------
@@ -193,10 +193,13 @@ _tty_make_name(struct tty_struct *tty, c

if (!tty) /* Hmm. NULL pointer. That's fun. */
strcpy(buf, "NULL tty");
else
- sprintf(buf, name,
- idx + tty->driver.name_base);
+ sprintf(buf, "%s%d", name, idx + tty->driver.name_base);

return buf;
}

(2) drivers/char/serial.c
---------------------
@@ -5387,7 +5387,7 @@ static int __init rs_init(void)
serial_driver.driver_name = "serial";
#endif
#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
- serial_driver.name = "tts/%d";
+ serial_driver.name = "tts/";
#else
serial_driver.name = "ttyS";
#endif

(3) drivers/char/whatever_other_driver.c
------------------------------------
@@ -5387,7 +5387,7 @@ static int __init wod_init(void)
wod_driver.driver_name = "whatever_other_driver";
#endif
#ifdef CONFIG_DEVFS_FS
- wod_driver.name = "tts/N%d";
+ wod_driver.name = "tts/N";
#else
wod_driver.name = "ttyN";
#endif

I've already suggested this in a previous msg, but nobody gave
feedback. I believe this is cleaner, as it removes the %d from
the driver.name field, while fixes the problem I reported.

- Since you'll patch the Cyclades driver, could you please add the
ifdef's for devfs?? The definitions are as follows:
- Callin devices: "tts/C%d" for devfs, "ttyC%d" for non-devfs.
- Callout devices: "cua/C%d" for devfs, "cub%d" for non-devfs
(no, this is NOT a typo, it's really cua/C and cub).

I ask this just to avoid sending a separate patch just for that.
I'd really appreciate it if you could do it along with your patch.
If you don't do it, no problem either.

Anyhow, thanks to all for the attention to this issue, and especially
to you, Andrew!

Later,
--
Ivan Passos -o)
Integration Manager, Cyclades - http://www.cyclades.com /\\
Project Leader, NetLinOS - http://www.netlinos.org _\_V
--------------------------------------------------------------------

2002-01-09 16:36:56