On Thu, 28 Jun 2001, MAEKAWA Masahide wrote:

> Matthew Jacob <mjacob@feral.com> wrote:
> >But I see no advantage to dynamic devsw additions if you don't also
> >propagate this where user applications, opening well known device names
> >in /dev, get the device they expect. It seems that it deals with part
> >of the problem, but not the really important part.
> 
> Of course, I understand my proposal is not atractive for userland.
> So I never mention userland (excluded config(8)).
> 
> The dynamic devnode configuration framework like devfs is useful.
> Yes, it can be implemented without the dynamic devsw framework.
> 
> But the dynamic configuration of kernel needs the dynamic devsw.
> The dynamic configuration of kernel needs 'configurable' kernel.
> 
> My proposal is not for the userland but for the kernel.

Yes, but as others have pointed out, if you add dynamic device numbers,
you introduce a real mess w/ the userland /dev.

I realize that your proposal had the ability to wire down node numbers,
but it first came across to me at least as suggesting that we go with
major numbers being dynamic in general.

If we hard-code all existing drivers, things should be fine.

How about this modification: divinde the major number space up and have
part of it not used for dunamic assignment - use that part only for
devices configured with an explicit major number. Say a port's majors end
aroun 100 or so, start the dynamic ones at say 150 or 200. That way you
avoid the case of a dynamic device grabbing the major number of a
well-known-but-not-attached driver. So in a machine w/o ide, no other
driver will show up at the wd's...

Take care,

Bill