On Wed, 4 Jan 2006, Quentin Garnier wrote:

>> 	I'm probably missing something here, but what would the
>> 	problem be with selecting new, unconflicting device ids
>> 	for both ports, and having the old device ids enabled under
>> 	a compat option (including a sysctl if preferred). New
>> 	kernels default to the compat enabled, and new MAKEDEV
>> 	creates new nodes.
>>
>> 	Document it clearly, enable it in the kernel on COMPAT_30 or
>> 	earlier, and make the kernel print a warning when it sees an
>> 	old form /dev/console node.
>>
>> 	No flag day, and we get a 'perfect' set of device numbers.
>>
>> 	Taken to an extreme its an oportunity to make _all_ ports work
>> 	from the same unified set of device numbers. Mmmm...
>
> I think this is a fine idea, but here's the list of devices with issues:
>
> ws, sd, ld, cd, raid, ccd    -> minor numbering issues (there might be
>                                even more)
> clockctl, systrace, cgd,
> wsfont, dpti, irframe,
> ksyms, mly, joy, cir,
> radio, kttcp                 -> different (and overlapping) major
>                                numbers.
>
> (This is a quick read of diff {amd64,i386}/conf/majors.*, I might be
> missing a couple devices.)
>
> That means we'd burn that many MI (or maybe MD--yet common to i386 and
> sparc64) major numbers to solve that issue.  Is it acceptable?

 	It would be to me, I can't say for others :) The only real
 	concern would be using file systems (or NFS servers) which
 	only support 16 bit major/minor numbers, but we already have
 	some devices that use the upper 16 bits, and people can use
 	init's automatic mfs + MAKEDEV workaround.

-- 
 		David/absolute       -- www.NetBSD.org: No hype required --