Re: 64-bit kdev_t - just for playing

["Kevin P. Fleming" <kpfleming@cox.net>]

Werner Almesberger wrote:
> Agreed, this is the difficult part. This probably means that the
> kernel will have to come with a default initrd-like setup that is
> built and attached by "make bzImage" and the like. I thought that
> people were quite actively working towards something like this ?
> 

Yes, this is being worked on actively. This will use the 2.5.x initramfs 
infrastructure, and when it's up and going there will be early-userspace tools 
included in the kernel tarball to do the basic things that need doing 
(essentially responding to hotplug events and creating/removing devices nodes as 
needed).

> By completely removing such policy from the kernel, we return to
> the status quo ante: user-visible names only need to be agreed on
> during early system bringup. After that, the "device file
> manager" takes over, and that one can just use a local device
> name database.

Yes, this is true. Ideally, the early-userspace version and the normal-userspace 
version will be the same tool (possibly compiled differently, but otherwise 
identical). The early-userspace version should not have to create many nodes for 
a "normal" kernel boot, so most of the remaining ones can be created once the 
user's preferred naming policy can be located and used. Really, the 
early-userspace version only needs to create two nodes that I can think of to 
satisfy the "normal" kernel boot process: /dev/console and /dev/root. However, 
both of these need to be created with knowledge of parameters passed on the 
kernel command line (as the kernel does now), so that when the hotplug process 
sees the appropriate device "appear" it can create the proper device node.