On Sun, Oct 16, 2005 at 11:11:54PM +0200, Quentin Garnier wrote:
> My point was, there is nothing currently in the tree preventing multiple
> major definitions in files.*, and preventing such a setup to work.

Interesting.
 
> > Effectively once a device has a major assigned within arch-specific
> > for some arch, it must have arch-specific major also for any new
> > architecture, AFAIK.
> 
> That's the political aspect of the issue.
> 
> I can add code in config(1) preventing that.  Just ask.  But maybe we
> want the fact that they can co-exist, though that would require more
> checks in MAKEDEV.awk to make sure it takes the generic values always,
> so that the arch-dependent value stays there for compatibility.

I believe we do want to keep using 'historic' major on architectures
with the major assigned in arch-specific range. So yes, I think
config(1) should prevent overriding device majors.

It might be neat (though perhaps somewhat confusing) to be able to
specify a major in MI range in such a way so that it would be
ignored if it's already assigned in arch-dependant range.  So that
e.g. new architectures would have use the new MI major, while 'old'
architectures would keep using the historic majors.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.cz/
-=- We can walk our road together if our goals are all the same;     -=-
-=- We can run alone and free if we pursue a different aim.          -=-