linux-kernel - Re: [PATCH RFC] char/tty_io: fix legacy pty name when more than 256 pty devices are requested

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Sep 2009 23:54:41 -0300
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Kay Sievers <kay.sievers@...y.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [PATCH RFC] char/tty_io: fix legacy pty name when more than 256
 pty devices are requested

Em Tue, 08 Sep 2009 17:26:39 -0700
"H. Peter Anvin" <hpa@...or.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/