mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Kay Sievers <kay.sievers@vrfy.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alan Cox <alan@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [PATCH RFC] char/tty_io: fix legacy pty name when more than 256 pty devices are requested
Date: Tue, 8 Sep 2009 23:54:41 -0300	[thread overview]
Message-ID: <20090908235441.04549a29@caramujo.chehab.org> (raw)
In-Reply-To: <4AA6F63F.7090009@zytor.com>

Em Tue, 08 Sep 2009 17:26:39 -0700
"H. Peter Anvin" <hpa@zytor.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

  reply	other threads:[~2009-09-09  2:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-08 17:49 Mauro Carvalho Chehab
2009-09-08 17:59 ` Alan Cox
2009-09-08 18:56   ` Mauro Carvalho Chehab
2009-09-08 18:59   ` [PATCH v2 " Mauro Carvalho Chehab
2009-09-08 22:48 ` [PATCH " H. Peter Anvin
2009-09-08 23:33   ` Mauro Carvalho Chehab
2009-09-09  0:26     ` H. Peter Anvin
2009-09-09  2:54       ` Mauro Carvalho Chehab [this message]
2009-09-09  4:46         ` H. Peter Anvin
2009-09-10  4:05           ` [PATCH] " Mauro Carvalho Chehab
2009-09-10  6:21             ` H. Peter Anvin
2009-09-10 12:33               ` Mauro Carvalho Chehab
2009-09-10 14:07                 ` Alan Cox
2009-09-10 15:57                   ` H. Peter Anvin
2009-09-10 16:08                   ` H. Peter Anvin
2009-09-10 19:12                     ` Mauro Carvalho Chehab
2009-09-10 19:17                       ` H. Peter Anvin
2009-09-10 20:05                         ` Mauro Carvalho Chehab
2009-09-10 20:35                           ` H. Peter Anvin
2009-09-10 23:23                       ` Alan Cox
2009-09-10 23:25                         ` H. Peter Anvin
2009-09-11  8:43                     ` Alan Cox
2009-09-10  4:13           ` [PATCH RFC] " Mauro Carvalho Chehab
2009-09-10  5:33             ` H. Peter Anvin
2009-09-10 12:18               ` Mauro Carvalho Chehab
2009-09-10 10:19             ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090908235441.04549a29@caramujo.chehab.org \
    --to=mchehab@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=alan@linux.intel.com \
    --cc=gregkh@suse.de \
    --cc=hpa@zytor.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®