There are some use cases where more than 256 pty device pairs are needed.
With kernel 2.6, the number of minors is not 256 anymore. So, it is
possible to have more than 256 pty devices, either by specifying the number
of tty devices at CONFIG_LEGACY_PTY_COUNT or by using tty.legacy_count parameter
at boot time.
However, the pty_line_name() only provides device names for the first
256 tty/pty devices.
As this function is used to generate the sysfs class name, any number of
pty devices above 256 will fail to properly register them at sysfs.
This is a bug, since there's no limits for the maximum number of legacy
pty devices at Kconfig or at pty.legacy_count.
It is important to preserve the old nomenclature for tty/pty devices for the
first 256 devices, to avoid breakage on existing applications and with udev.
So, in order to allow more pty devices, the nomenclature were extended for
the devices with minor 256 or above. For those, the nomenclature will be:
ttyf0000-ttfpffff (pty slave)
ptyf0000-ttyfffff (pty master)
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index a3afa0c..fdea89b 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1110,9 +1110,15 @@ static void pty_line_name(struct tty_driver *driver, int index, char *p)
{
int i = index + driver->name_base;
/* ->name is initialized to "ttyp", but "tty" is expected */
- sprintf(p, "%s%c%x",
- driver->subtype == PTY_TYPE_SLAVE ? "tty" : driver->name,
- ptychar[i >> 4 & 0xf], i & 0xf);
+ if (i < 256) {
+ sprintf(p, "%s%c%x",
+ driver->subtype == PTY_TYPE_SLAVE ? "tty" : driver->name,
+ ptychar[i >> 4 & 0xf], i & 0xf);
+ } else { /* Up to 4096 */
+ sprintf(p, "%sf%04x",
+ driver->subtype == PTY_TYPE_SLAVE ? "tty" : driver->name,
+ i - 256);
+ }
}
/**
Cheers,
Mauro
> So, in order to allow more pty devices, the nomenclature were extended for
> the devices with minor 256 or above. For those, the nomenclature will be:
> ttyf0000-ttfpffff (pty slave)
> ptyf0000-ttyfffff (pty master)
>
> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
This fine and the namespace is free - but you need to update
Documentation/devices.txt as well please.
Alan
Em Tue, 8 Sep 2009 18:59:26 +0100
Alan Cox <[email protected]> escreveu:
> > So, in order to allow more pty devices, the nomenclature were extended for
> > the devices with minor 256 or above. For those, the nomenclature will be:
> > ttyf0000-ttfpffff (pty slave)
> > ptyf0000-ttyfffff (pty master)
> >
> > Signed-off-by: Mauro Carvalho Chehab <[email protected]>
>
> This fine and the namespace is free - but you need to update
> Documentation/devices.txt as well please.
Thanks for review. I'll document it and send a version 2 of the patch with the
devices.txt updated accordingly.
Cheers,
Mauro
With kernel 2.6, the number of minors is not 255 anymore. So, it is
possible to have more than 255 pty devices.
However, the pty_line_name() only provides device names for the first
256 tty/pty devices.
This is a bug, since there's no limits for the maximum number of legacy
pty devices at Kconfig or at pty.legacy_count.
This patch preserves the old nomenclature for tty/pty devices for the
first 256 devices. After that, it names the next devices as:
ttyf0000-ttfpffff (pty slave)
ptyf0000-ttyfffff (pty master)
This way, the existing udev rules for legacy pty devices to not
break. Only after minor 255, it will start to use the new nomenclature.
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
---
Version 2: devices.txt namespace doc were updated accordingly.
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 53d64d3..cfd3e20 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -114,18 +114,27 @@ Your cooperation is appreciated.
the initrd.
2 char Pseudo-TTY masters
- 0 = /dev/ptyp0 First PTY master
- 1 = /dev/ptyp1 Second PTY master
+ 0 = /dev/ptyp0 First PTY master
+ 1 = /dev/ptyp1 Second PTY master
...
- 255 = /dev/ptyef 256th PTY master
+ 255 = /dev/ptyef 256th PTY master
+ 256 = /dev/ptyf0000 257th PTY slave
+ 257 = /dev/ptyf0001 258th PTY slave
+ ...
+ 65791 = /dev/ptyfffff 65791 PTY slave
- Pseudo-tty's are named as follows:
+ Pseudo-tty's up to 256 are named as follows:
* Masters are "pty", slaves are "tty";
* the fourth letter is one of pqrstuvwxyzabcde indicating
the 1st through 16th series of 16 pseudo-ttys each, and
* the fifth letter is one of 0123456789abcdef indicating
the position within the series.
+ Pseudo-tty's above 256 are named as follows:
+ * Masters are "ptyf", slaves are "ttyf";
+ * the fifth to eighth letters are hexadecimal digits
+ indicating the position within the series.
+
These are the old-style (BSD) PTY devices; Unix98
devices are on major 128 and above and use the PTY
master multiplex (/dev/ptmx) to acquire a PTY on
@@ -189,10 +198,14 @@ Your cooperation is appreciated.
the drive type is insignificant for these devices.
3 char Pseudo-TTY slaves
- 0 = /dev/ttyp0 First PTY slave
- 1 = /dev/ttyp1 Second PTY slave
- ...
- 255 = /dev/ttyef 256th PTY slave
+ 0 = /dev/ttyp0 First PTY slave
+ 1 = /dev/ttyp1 Second PTY slave
+ ...
+ 255 = /dev/ttyef 256th PTY slave
+ 256 = /dev/ttyf0000 257th PTY slave
+ 257 = /dev/ttyf0001 258th PTY slave
+ ...
+ 65791 = /dev/ttyfffff 65791 PTY slave
These are the old-style (BSD) PTY devices; Unix98
devices are on major 136 and above.
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index a3afa0c..fdea89b 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1110,9 +1110,15 @@ static void pty_line_name(struct tty_driver *driver, int index, char *p)
{
int i = index + driver->name_base;
/* ->name is initialized to "ttyp", but "tty" is expected */
- sprintf(p, "%s%c%x",
- driver->subtype == PTY_TYPE_SLAVE ? "tty" : driver->name,
- ptychar[i >> 4 & 0xf], i & 0xf);
+ if (i < 256) {
+ sprintf(p, "%s%c%x",
+ driver->subtype == PTY_TYPE_SLAVE ? "tty" : driver->name,
+ ptychar[i >> 4 & 0xf], i & 0xf);
+ } else { /* Up to 4096 */
+ sprintf(p, "%sf%04x",
+ driver->subtype == PTY_TYPE_SLAVE ? "tty" : driver->name,
+ i - 256);
+ }
}
/**
Cheers,
Mauro
On 09/08/2009 10:49 AM, Mauro Carvalho Chehab wrote:
>
> It is important to preserve the old nomenclature for tty/pty devices for the
> first 256 devices, to avoid breakage on existing applications and with udev.
>
> So, in order to allow more pty devices, the nomenclature were extended for
> the devices with minor 256 or above. For those, the nomenclature will be:
> ttyf0000-ttfpffff (pty slave)
> ptyf0000-ttyfffff (pty master)
>
This would seem to be a somewhat silly way to extend it, especially
given the arbitrary artificial limit of just over 2^16 entries.
If you're going to do this, I would suggest using the following
namespace, as such:
[pt]ty[p-za-e][0-9a-f]+
sprintf(name, "%cty%c%x", slave ? 't' : 'p',
"pqrstuvwxyzabcde"[(index >> 4) & 15],
((index >> 4) & ~15) | (index & 15));
No arbitrary limits, and it still extends the existing namespace with
some reasonable continuity. It means bits [7:4] are weirdly encoded,
but we get straightforward backwards compatibility as a result.
-hpa
Em Tue, 08 Sep 2009 15:48:48 -0700
"H. Peter Anvin" <[email protected]> escreveu:
> On 09/08/2009 10:49 AM, Mauro Carvalho Chehab wrote:
> >
> > It is important to preserve the old nomenclature for tty/pty devices for the
> > first 256 devices, to avoid breakage on existing applications and with udev.
> >
> > So, in order to allow more pty devices, the nomenclature were extended for
> > the devices with minor 256 or above. For those, the nomenclature will be:
> > ttyf0000-ttfpffff (pty slave)
> > ptyf0000-ttyfffff (pty master)
> >
>
> This would seem to be a somewhat silly way to extend it, especially
> given the arbitrary artificial limit of just over 2^16 entries.
> If you're going to do this, I would suggest using the following
> namespace, as such:
>
> [pt]ty[p-za-e][0-9a-f]+
To be backward compatible, the format should be, at least:
[pt]ty[p-za-e][0-9a-f].+
otherwise, it can potentially break backward compatibility, as the first 10 devices will be like:
/dev/ttyp0
/dev/ttyp1
...
instead of:
/dev/ttyp00
/dev/ttyp01
>
> sprintf(name, "%cty%c%x", slave ? 't' : 'p',
> "pqrstuvwxyzabcde"[(index >> 4) & 15],
> ((index >> 4) & ~15) | (index & 15));
We may use this, instead:
sprintf(name, "%cty%c%02x", slave ? 't' : 'p',
"pqrstuvwxyzabcde"[(index >> 4) & 15],
((index >> 4) & ~15) | (index & 15));
> No arbitrary limits, and it still extends the existing namespace with
> some reasonable continuity. It means bits [7:4] are weirdly encoded,
> but we get straightforward backwards compatibility as a result.
But it will also be a little more weird.
>
Cheers,
Mauro
On 09/08/2009 04:33 PM, Mauro Carvalho Chehab wrote:
>
>> If you're going to do this, I would suggest using the following
>> namespace, as such:
>>
>> [pt]ty[p-za-e][0-9a-f]+
>
> To be backward compatible, the format should be, at least:
>
> [pt]ty[p-za-e][0-9a-f].+
>
> otherwise, it can potentially break backward compatibility, as the first 10 devices will be like:
> /dev/ttyp0
> /dev/ttyp1
> ...
>
> instead of:
>
> /dev/ttyp00
> /dev/ttyp01
>
Correct. You're missing the point: if you follow my recipe, the legacy
names fall out of the same algorithm. The first 256 will have the
traditional names, fully compatible, the 256th entry will be
/dev/ttyp10, and so on.
>>
>> sprintf(name, "%cty%c%x", slave ? 't' : 'p',
>> "pqrstuvwxyzabcde"[(index >> 4) & 15],
>> ((index >> 4) & ~15) | (index & 15));
>
> We may use this, instead:
>
> sprintf(name, "%cty%c%02x", slave ? 't' : 'p',
> "pqrstuvwxyzabcde"[(index >> 4) & 15],
> ((index >> 4) & ~15) | (index & 15));
>
>> No arbitrary limits, and it still extends the existing namespace with
>> some reasonable continuity. It means bits [7:4] are weirdly encoded,
>> but we get straightforward backwards compatibility as a result.
>
> But it will also be a little more weird.
IMO, no less weird than a random shift from one naming algorithm to
another in the middle of the sequence.
-hpa
Em Tue, 08 Sep 2009 17:26:39 -0700
"H. Peter Anvin" <[email protected]> escreveu:
> Correct. You're missing the point: if you follow my recipe, the legacy
> names fall out of the same algorithm. The first 256 will have the
> traditional names, fully compatible, the 256th entry will be
> /dev/ttyp10, and so on.
>
> >>
> >> sprintf(name, "%cty%c%x", slave ? 't' : 'p',
> >> "pqrstuvwxyzabcde"[(index >> 4) & 15],
> >> ((index >> 4) & ~15) | (index & 15));
> > But it will also be a little more weird.
>
> IMO, no less weird than a random shift from one naming algorithm to
> another in the middle of the sequence.
Ok, your algorithm will be fully compatible with the old naming system, as
you're encoding the nibbles on this order:
[7:4][3:0][*:8]
>From one side, I liked the idea of not having any arbitrary maximum limit, but
from other side, It seems easier to implement than to describe it in English,
at devices.txt. Maybe the solution is to explain it by examples.
Also, if we look at the current device designation, we already have some rule
changes.
For example, for SCSI discs, there are lots of different majors: major 8 (for
the first 16 disks), major 65 (for the next 16 disks), major 66 (for the next
16 disks), major 68 (for more 16 disks)... For sure something that comes from
the time where minors were limited to 256.
Another example: major 112 block has a new rule for devices above 26 (well,
something close to what you're proposing), except that they are just reverting
the nibbles order, instead of using a weird order just to keep backward
compatibility.
Anyway, I'll prepare a new RFC using your algorithm and documenting it.
Cheers,
Mauro
On 09/08/2009 07:54 PM, Mauro Carvalho Chehab wrote:
>>
>> IMO, no less weird than a random shift from one naming algorithm to
>> another in the middle of the sequence.
>
> Ok, your algorithm will be fully compatible with the old naming system, as
> you're encoding the nibbles on this order:
> [7:4][3:0][*:8]
>
Actually it's [7:4][*:8][3:0]. It was the easiest way to get backwards
compatibility, since it allowed for the use of s[n]printf(). It's not
by any means the only possibility, but I think the easiest one to describe.
> From one side, I liked the idea of not having any arbitrary maximum limit, but
> from other side, It seems easier to implement than to describe it in English,
> at devices.txt. Maybe the solution is to explain it by examples.
>
> Also, if we look at the current device designation, we already have some rule
> changes.
That doesn't mean it's a good idea.
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
With kernel 2.6, the number of minors is not 255 anymore. So, it is
possible to have more than 255 pty devices.
However, the pty_line_name() only provides device names for the first
256 tty/pty devices. After that, it will duplicate existing names while
trying to register at sysfs.
This is a bug, since there's no limits for the maximum number of legacy
pty devices at Kconfig or at pty.legacy_count.
This fix preserves the old nomenclature for tty/pty devices for the
first 256 devices.
To preserve backward compatibility, the device index is broken into
nibbles, each nibble generating a letter, at the following order:
* The second nibble of the index is represented by one of pqrstuvwxyzabcde
letters, indicating the 1st through 16th nibble value;
* The remaining nibbles are represented by one of 0123456789abcdef letters,
indicating the 1st through 16th nibble value, starting from the most
significative nibble to the least significative nibble, excluding the
second nibble (that were already represented).
So, device numbers will be:
0 = ptyp0
1 = ptyp1
...
255 = ptyef
256 = ptyp10
...
4095 = ptyeff
4096 = ptyp100
...
65535 = ptyefff
65536 = ptyp1000
...
Thanks to H. Peter Anvin <[email protected]> for proposing this algorithm.
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 53d64d3..6a74635 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -114,17 +114,30 @@ Your cooperation is appreciated.
the initrd.
2 char Pseudo-TTY masters
- 0 = /dev/ptyp0 First PTY master
- 1 = /dev/ptyp1 Second PTY master
+ 0 = /dev/ptyp0 First PTY master
+ 1 = /dev/ptyp1 Second PTY master
...
- 255 = /dev/ptyef 256th PTY master
+ 255 = /dev/ptyef 256th PTY master
+ 256 = /dev/ptyp10 257th PTY master
+ 257 = /dev/ptyp11 258th PTY master
+ ...
+ 4095 = /dev/ptyeff 4095th PTY master
+ 4096 = /dev/ptyp100 4096th PTY master
+ ...
Pseudo-tty's are named as follows:
- * Masters are "pty", slaves are "tty";
- * the fourth letter is one of pqrstuvwxyzabcde indicating
- the 1st through 16th series of 16 pseudo-ttys each, and
- * the fifth letter is one of 0123456789abcdef indicating
- the position within the series.
+ Masters are "pty", slaves are "tty";
+
+ The device index is broken into nibbles, each nibble
+ generating a letter, at the following order:
+ * The second nibble of the index is represented by one
+ of pqrstuvwxyzabcde letters, indicating the 1st
+ through 16th nibble value;
+ * The remaining nibbles are represented by one of
+ 0123456789abcdef letters, indicating the 1st through
+ 16th nibble value, starting from the most
+ significative nibble to the least significative nibble,
+ excluding the second nibble.
These are the old-style (BSD) PTY devices; Unix98
devices are on major 128 and above and use the PTY
@@ -189,10 +202,18 @@ Your cooperation is appreciated.
the drive type is insignificant for these devices.
3 char Pseudo-TTY slaves
- 0 = /dev/ttyp0 First PTY slave
- 1 = /dev/ttyp1 Second PTY slave
- ...
- 255 = /dev/ttyef 256th PTY slave
+ 0 = /dev/ttyp0 First PTY slave
+ 1 = /dev/ttyp1 Second PTY slave
+ ...
+ 255 = /dev/ttyef 256th PTY slave
+ 256 = /dev/ttyp10 257th PTY slave
+ 257 = /dev/ttyp11 258th PTY slave
+ ...
+ 4095 = /dev/ttyeff 4095th PTY slave
+ 4096 = /dev/ttyp100 4096th PTY slave
+ ...
+
+ See char major number 2 for the used rules to name them.
These are the old-style (BSD) PTY devices; Unix98
devices are on major 136 and above.
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index a3afa0c..db86461 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1093,8 +1093,6 @@ ssize_t redirected_tty_write(struct file *file, const char __user *buf,
return tty_write(file, buf, count, ppos);
}
-static char ptychar[] = "pqrstuvwxyzabcde";
-
/**
* pty_line_name - generate name for a pty
* @driver: the tty driver in use
@@ -1108,11 +1106,23 @@ static char ptychar[] = "pqrstuvwxyzabcde";
*/
static void pty_line_name(struct tty_driver *driver, int index, char *p)
{
+ static char ptychar[] = "pqrstuvwxyzabcde";
+
int i = index + driver->name_base;
- /* ->name is initialized to "ttyp", but "tty" is expected */
+ /*
+ * On slave, driver->name is initialized to "ttyp",
+ * but "tty" is expected.
+ * The index part of the name is broken into nibbles, following
+ * this sequence:
+ * The second nibble encoded with ptychar;
+ * The first nibble, printed in hexadecimal;
+ * The other nibbles, printed in hexadecimal.
+ * This is done to preserve backward compatibility with the older
+ * naming conventions.
+ */
sprintf(p, "%s%c%x",
driver->subtype == PTY_TYPE_SLAVE ? "tty" : driver->name,
- ptychar[i >> 4 & 0xf], i & 0xf);
+ ptychar[(i >> 4) & 0xf], (i & 0xf) | ((i >> 4) & ~0xf);
}
/**
Em Tue, 08 Sep 2009 21:46:01 -0700
"H. Peter Anvin" <[email protected]> escreveu:
> Actually it's [7:4][*:8][3:0]. It was the easiest way to get backwards
> compatibility, since it allowed for the use of s[n]printf(). It's not
> by any means the only possibility, but I think the easiest one to describe.
>
> > From one side, I liked the idea of not having any arbitrary maximum limit, but
> > from other side, It seems easier to implement than to describe it in English,
> > at devices.txt. Maybe the solution is to explain it by examples.
> >
> > Also, if we look at the current device designation, we already have some rule
> > changes.
>
> That doesn't mean it's a good idea.
True. Given the idea of using an unique algorithm to populate the namespace, I agree
that your proposal is a good alternative.
I just sent the patch with the feedbacks I had. I tried to do my best to describe it in
simple yet precise terms at devices.txt.
Thanks,
Mauro
On 09/09/2009 09:13 PM, Mauro Carvalho Chehab wrote:
> Em Tue, 08 Sep 2009 21:46:01 -0700
> "H. Peter Anvin" <[email protected]> escreveu:
>
>> Actually it's [7:4][*:8][3:0]. It was the easiest way to get backwards
>> compatibility, since it allowed for the use of s[n]printf(). It's not
>> by any means the only possibility, but I think the easiest one to describe.
>>
>>> From one side, I liked the idea of not having any arbitrary maximum limit, but
>>> from other side, It seems easier to implement than to describe it in English,
>>> at devices.txt. Maybe the solution is to explain it by examples.
>>>
>>> Also, if we look at the current device designation, we already have some rule
>>> changes.
>>
>> That doesn't mean it's a good idea.
>
> True. Given the idea of using an unique algorithm to populate the namespace, I agree
> that your proposal is a good alternative.
>
> I just sent the patch with the feedbacks I had. I tried to do my best to describe it in
> simple yet precise terms at devices.txt.
>
Looks good, except:
s/nibble/nybble/
"nybble" is to "nibble" what "byte" is to "bite".
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 09/09/2009 09:05 PM, Mauro Carvalho Chehab wrote:
> {
> + static char ptychar[] = "pqrstuvwxyzabcde";
> +
Oh yes, this should be "static const char ...".
> + * The second nibble encoded with ptychar;
> + * The first nibble, printed in hexadecimal;
> + * The other nibbles, printed in hexadecimal.
The last two are in the wrong order (and you reversed the order of the
code from my example, which made that harder to see.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
> True. Given the idea of using an unique algorithm to populate the
> namespace, I agree that your proposal is a good alternative.
>
> I just sent the patch with the feedbacks I had. I tried to do my best
> to describe it in simple yet precise terms at devices.txt.
I really wouldn't worry too much. I'm not aware of a single
distribution which still uses the old BSD style pty devices. So its not
as if this is anything but a theoretical problem being addressed.
Alan
Em Wed, 09 Sep 2009 22:33:31 -0700
"H. Peter Anvin" <[email protected]> escreveu:
> On 09/09/2009 09:13 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 08 Sep 2009 21:46:01 -0700
> > "H. Peter Anvin" <[email protected]> escreveu:
> >
> >> Actually it's [7:4][*:8][3:0]. It was the easiest way to get backwards
> >> compatibility, since it allowed for the use of s[n]printf(). It's not
> >> by any means the only possibility, but I think the easiest one to describe.
> >>
> >>> From one side, I liked the idea of not having any arbitrary maximum limit, but
> >>> from other side, It seems easier to implement than to describe it in English,
> >>> at devices.txt. Maybe the solution is to explain it by examples.
> >>>
> >>> Also, if we look at the current device designation, we already have some rule
> >>> changes.
> >>
> >> That doesn't mean it's a good idea.
> >
> > True. Given the idea of using an unique algorithm to populate the namespace, I agree
> > that your proposal is a good alternative.
> >
> > I just sent the patch with the feedbacks I had. I tried to do my best to describe it in
> > simple yet precise terms at devices.txt.
> >
>
> Looks good, except:
>
> s/nibble/nybble/
>
> "nybble" is to "nibble" what "byte" is to "bite".
Well, on all books I studied, this were written as "nibble" meaning half byte.
A quick research at the Internet shows that both terms are accepted:
http://en.wikipedia.org/wiki/Nibble
http://freeware-reviews.blogspot.com/2005/10/nibble-or-nybble.html
http://www.techterms.com/definition/nybble
http://www.mondofacto.com/facts/dictionary?nybble
Yet, nibble results in much more matches. So, IMO, we should keep using nibble.
Cheers,
Mauro
char/tty_io: fix pty name convention
With kernel 2.6, the number of minors is not 255 anymore. So, it is
possible to have more than 255 pty devices.
However, the pty_line_name() only provides device names for the first
256 tty/pty devices.
This is a bug, since there's no limits for the maximum number of legacy
pty devices at Kconfig or at pty.legacy_count.
This patch preserves the old nomenclature for tty/pty devices for the
first 256 devices.
To preserve backward compatibility, the device index is broken into
nibbles, each nibble generating a letter, at the following order:
* The second nibble of the index is represented by one of pqrstuvwxyzabcde
letters, indicating the 1st through 16th nibble value;
* The remaining nibbles are represented by one of 0123456789abcdef letters,
indicating the 1st through 16th nibble value, starting from the most
significative nibble to the least significative nibble, excluding the
second nibble (that were already represented).
So, device numbers will be:
0 = ptyp0
1 = ptyp1
...
255 = ptyef
256 = ptyp10
...
4095 = ptyeff
4096 = ptyp100
...
65535 = ptyefff
65536 = ptyp1000
...
Thanks to H. Peter Anvin <[email protected]> for proposing this algorithm.
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 53d64d3..6a74635 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -114,17 +114,30 @@ Your cooperation is appreciated.
the initrd.
2 char Pseudo-TTY masters
- 0 = /dev/ptyp0 First PTY master
- 1 = /dev/ptyp1 Second PTY master
+ 0 = /dev/ptyp0 First PTY master
+ 1 = /dev/ptyp1 Second PTY master
...
- 255 = /dev/ptyef 256th PTY master
+ 255 = /dev/ptyef 256th PTY master
+ 256 = /dev/ptyp10 257th PTY master
+ 257 = /dev/ptyp11 258th PTY master
+ ...
+ 4095 = /dev/ptyeff 4095th PTY master
+ 4096 = /dev/ptyp100 4096th PTY master
+ ...
Pseudo-tty's are named as follows:
- * Masters are "pty", slaves are "tty";
- * the fourth letter is one of pqrstuvwxyzabcde indicating
- the 1st through 16th series of 16 pseudo-ttys each, and
- * the fifth letter is one of 0123456789abcdef indicating
- the position within the series.
+ Masters are "pty", slaves are "tty";
+
+ The device index is broken into nibbles, each nibble
+ generating a letter, at the following order:
+ * The second nibble of the index is represented by one
+ of pqrstuvwxyzabcde letters, indicating the 1st
+ through 16th nibble value;
+ * The remaining nibbles are represented by one of
+ 0123456789abcdef letters, indicating the 1st through
+ 16th nibble value, starting from the most
+ significative nibble to the least significative nibble,
+ excluding the second nibble.
These are the old-style (BSD) PTY devices; Unix98
devices are on major 128 and above and use the PTY
@@ -189,10 +202,18 @@ Your cooperation is appreciated.
the drive type is insignificant for these devices.
3 char Pseudo-TTY slaves
- 0 = /dev/ttyp0 First PTY slave
- 1 = /dev/ttyp1 Second PTY slave
- ...
- 255 = /dev/ttyef 256th PTY slave
+ 0 = /dev/ttyp0 First PTY slave
+ 1 = /dev/ttyp1 Second PTY slave
+ ...
+ 255 = /dev/ttyef 256th PTY slave
+ 256 = /dev/ttyp10 257th PTY slave
+ 257 = /dev/ttyp11 258th PTY slave
+ ...
+ 4095 = /dev/ttyeff 4095th PTY slave
+ 4096 = /dev/ttyp100 4096th PTY slave
+ ...
+
+ See char major number 2 for the used rules to name them.
These are the old-style (BSD) PTY devices; Unix98
devices are on major 136 and above.
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index a3afa0c..de6d617 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1093,8 +1093,6 @@ ssize_t redirected_tty_write(struct file *file, const char __user *buf,
return tty_write(file, buf, count, ppos);
}
-static char ptychar[] = "pqrstuvwxyzabcde";
-
/**
* pty_line_name - generate name for a pty
* @driver: the tty driver in use
@@ -1108,11 +1106,23 @@ static char ptychar[] = "pqrstuvwxyzabcde";
*/
static void pty_line_name(struct tty_driver *driver, int index, char *p)
{
+ static const char ptychar[] = "pqrstuvwxyzabcde";
+
int i = index + driver->name_base;
- /* ->name is initialized to "ttyp", but "tty" is expected */
+ /*
+ * On slave, driver->name is initialized to "ttyp",
+ * but "tty" is expected.
+ * The index part of the name is broken into nibbles, following
+ * this sequence:
+ * The second nibble encoded with ptychar;
+ * The other nibbles, printed in hexadecimal, from most to
+ * the least significant nibble.
+ * This is done to preserve backward compatibility with the older
+ * naming conventions.
+ */
sprintf(p, "%s%c%x",
driver->subtype == PTY_TYPE_SLAVE ? "tty" : driver->name,
- ptychar[i >> 4 & 0xf], i & 0xf);
+ ptychar[(i >> 4) & 0xf], (i & 0xf) | ((i >> 4) & ~0xf));
}
/**
Cheers,
Mauro
> * The remaining nibbles are represented by one of 0123456789abcdef letters,
> indicating the 1st through 16th nibble value, starting from the most
> significative nibble to the least significative nibble, excluding the
> second nibble (that were already represented).
This is a real step back.
It now wastes all the tty[e-p]%d namespace. ttyp%d for > 255 at least
only uses one for this irrelevant area.
I actually have another proposal having reviewed the user space code.
Limit the BSD ptys to 256. Nothing uses them, the C library routines for
their allocation would need glibc modifying (which takes about five years
for a tty change it seems anyway). It's basically a huge amount of work
for no purpose at all.
So lets limit BSD ptys (unused anyway) to 256 and be done with it.
Alan
On 09/10/2009 07:07 AM, Alan Cox wrote:
> I actually have another proposal having reviewed the user space code.
>
> Limit the BSD ptys to 256. Nothing uses them, the C library routines for
> their allocation would need glibc modifying (which takes about five years
> for a tty change it seems anyway). It's basically a huge amount of work
> for no purpose at all.
>
> So lets limit BSD ptys (unused anyway) to 256 and be done with it.
IMO this is the right thing to do (and in fact what the current kernel
does, explicitly, via Kconfig); I guess I assumed Mauro had a specific
reason for breaking it, but there are multiple reasons to NOT do this:
a) the userspace code needs to be changed regardless, in an arbitrary
number of places.
b) noone uses them, except the occasional dedicated pipe which wants
a predefined name.
c) the memory used is statically allocated.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 09/10/2009 07:07 AM, Alan Cox wrote:
>
> This is a real step back.
>
> It now wastes all the tty[e-p]%d namespace. ttyp%d for > 255 at least
> only uses one for this irrelevant area.
>
Honestly, I *really* don't think the [pt]ty[p-za-e]* namespace should be
used for another purpose, at least until BSD ptys are killed dead, so in
that sense expanding tty[p-za-e][0-9a-f] to tty[p-za-e][0-9a-f]+ is
hardly significant in the namespace pollution sense. Can you imagine
ttyp1 being a BSD pty and ttyp10 being a completely different kind of
device?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
Em Thu, 10 Sep 2009 09:08:39 -0700
"H. Peter Anvin" <[email protected]> escreveu:
> On 09/10/2009 07:07 AM, Alan Cox wrote:
> >
> > This is a real step back.
> >
> > It now wastes all the tty[e-p]%d namespace. ttyp%d for > 255 at least
> > only uses one for this irrelevant area.
> >
>
> Honestly, I *really* don't think the [pt]ty[p-za-e]* namespace should be
> used for another purpose, at least until BSD ptys are killed dead, so in
> that sense expanding tty[p-za-e][0-9a-f] to tty[p-za-e][0-9a-f]+ is
> hardly significant in the namespace pollution sense. Can you imagine
> ttyp1 being a BSD pty and ttyp10 being a completely different kind of
> device?
+1. Reusing the namespace after tty[p-za-e][0-9a-f] doesn't seem to be good, IMHO.
In the case of the BSD sockets, the patch is not just an userless fix. This is
interesting when some applications are ported from other Unix'es and still uses BSD
pty's, since several other Unix flavors were defining a higher namespace size.
For example, on zOS Unix, a pty device seems to allow up to 10.000 pty numbers (in the
specific case of zOS Unix, they seem to be defined as /dev/[pt]typ[0-9]...) as shown at:
http://www.redbooks.ibm.com/redbooks/pdfs/sg245228.pdf
Cheers,
Mauro
On 09/10/2009 12:12 PM, Mauro Carvalho Chehab wrote:
>
> +1. Reusing the namespace after tty[p-za-e][0-9a-f] doesn't seem to be good, IMHO.
>
I think it's better to extend the strings with the current prefixes than
to burn the virgin ttyf* prefix.
> In the case of the BSD sockets, the patch is not just an userless fix. This is
> interesting when some applications are ported from other Unix'es and still uses BSD
> pty's, since several other Unix flavors were defining a higher namespace size.
>
> For example, on zOS Unix, a pty device seems to allow up to 10.000 pty numbers (in the
> specific case of zOS Unix, they seem to be defined as /dev/[pt]typ[0-9]...) as shown at:
> http://www.redbooks.ibm.com/redbooks/pdfs/sg245228.pdf
>
Yes, but you have to port the application *anyway* do deal with the
namespace. BSD tty allocation is done largely by each application,
which makes it even worse. Furthermore, there is the static allocation
issue, so unless there is a concrete application which needs this *and*
cannot be ported to Unix98 ptys (which is the Right Thing[TM] to do) I
think Alan is right.
-hpa
Em Thu, 10 Sep 2009 12:17:28 -0700
"H. Peter Anvin" <[email protected]> escreveu:
> > In the case of the BSD sockets, the patch is not just an userless fix. This is
> > interesting when some applications are ported from other Unix'es and still uses BSD
> > pty's, since several other Unix flavors were defining a higher namespace size.
> >
> > For example, on zOS Unix, a pty device seems to allow up to 10.000 pty numbers (in the
> > specific case of zOS Unix, they seem to be defined as /dev/[pt]typ[0-9]...) as shown at:
> > http://www.redbooks.ibm.com/redbooks/pdfs/sg245228.pdf
> >
>
> Yes, but you have to port the application *anyway* do deal with the
> namespace.
Or create some udev rules for that.
> BSD tty allocation is done largely by each application,
> which makes it even worse. Furthermore, there is the static allocation
> issue, so unless there is a concrete application which needs this *and*
> cannot be ported to Unix98 ptys (which is the Right Thing[TM] to do) I
> think Alan is right.
The amount of static allocation space can be controlled via pty.legacy_count
boot parameter. It overrides whatever specified at CONFIG_LEGACY_PTY_COUNT.
You can even let LEGACY_PTY_COUNT = 0 and enable the actual numbers of needed
legacy ptys via boot parameter, where needed. So, this is not a problem on a
real situation.
Cheers,
Mauro
On 09/10/2009 01:05 PM, Mauro Carvalho Chehab wrote:
>>
>> Yes, but you have to port the application *anyway* do deal with the
>> namespace.
>
> Or create some udev rules for that.
>
udev rules does zero good, because the way the BSD ptys go, the
application itself needs to understand what the naming scheme is. So it
is an application-by-application slog.
>> BSD tty allocation is done largely by each application,
>> which makes it even worse. Furthermore, there is the static allocation
>> issue, so unless there is a concrete application which needs this *and*
>> cannot be ported to Unix98 ptys (which is the Right Thing[TM] to do) I
>> think Alan is right.
>
> The amount of static allocation space can be controlled via pty.legacy_count
> boot parameter. It overrides whatever specified at CONFIG_LEGACY_PTY_COUNT.
> You can even let LEGACY_PTY_COUNT = 0 and enable the actual numbers of needed
> legacy ptys via boot parameter, where needed. So, this is not a problem on a
> real situation.
It still means you are statically allocating a fixed number at boot time.
-hpa
> In the case of the BSD sockets, the patch is not just an userless fix. This is
It's useless.
> interesting when some applications are ported from other Unix'es and still uses BSD
> pty's, since several other Unix flavors were defining a higher namespace size.
They won't work because the glibc pty name handling only does the 256
devices. Given glibc still hasn't picked up tty changes from several
years ago I doubt it'll ever pick up a naming change.
BSD pty is dead. It has all sorts of problems including time taken to
find a new port being dependant on ports currently in use. The amount of
code that cares about it is close to nil, that which cares about it uses
glibc BSD pty helper code so won't work with > 256 anyway.
Alan
On 09/10/2009 04:23 PM, Alan Cox wrote:
>
> They won't work because the glibc pty name handling only does the 256
> devices. Given glibc still hasn't picked up tty changes from several
> years ago I doubt it'll ever pick up a naming change.
>
> BSD pty is dead. It has all sorts of problems including time taken to
> find a new port being dependant on ports currently in use. The amount of
> code that cares about it is close to nil, that which cares about it uses
> glibc BSD pty helper code so won't work with > 256 anyway.
>
I don't think they use glibc helper code, or they would automatically
end up with Unix98 ptys. Rather, the remaining users of BSD ptys are
probably those where the application hard-codes the pty naming for each
platform it ran on... which is even worse of a compatibility nightmare,
of course.
-hpa
> hardly significant in the namespace pollution sense. Can you imagine
> ttyp1 being a BSD pty and ttyp10 being a completely different kind of
> device?
No but I can imagine
ttyp1
ttypr0
ttypr1
being different devices (and we have upper case examples of that where
single case is running tight now)
Anyway, we don't need over 256 BSD pty devices and the libraries can't do
it so I still believe its a waste of electrons