My main conclusions are:
* Different devices (even under one subsystem) give
very different amount of info about themselves.
* there are devices for which it is impossible to get any
specific info.
* major:minor is not good
* current devfs is also not good enough
* Policy does not belong to kernel. Also 'There cant be any
fixed rules'.
* There cant be 100% Right solution, as interfacing with devices
has too much this 'Real World' in it.
* Also there cant be 100% accepted solution as people too
have quite a lot of this 'Real World' with them...
* and backwards compatibility.
So I guess I cant make situation worse by submitting my idea of
devfs2. I am aiming it at near 90% ;)
Now. devfs2 is not intended to be mounted to /dev
Rather it should live in /devfs or /proc/sys/devices
or /devices.
So /devices/ should like /proc consist of numbered directories.
Main idea is that one dir will describe one 'device node'. And
only one. I call the dir num 'devid'. It will be unique for
one session (boot-shutdown). It will be given out in ascending
order. Devices detected later get bigger devid. If device goes
away and comes back it will get new devid. Lets say devid is
64bit int starting from 0 so I need not worry about wrapping.
Now files. And I want to emphasize that this is only sketch,
I want to express general idea, not say that this is only way.
/name
short name. [ urandom, null, zero - devfsd2 can simply
use that name and drop it into /dev, or under
/dev/$(parent)/ ]
/parent
The parent devid. Not mandatory but most of devices
can be said to be 'under' something.
/info
this is consist of 'key: value\n' pairs. All relevant
info the kernel has about this device. Most
common/typical values (all?) can be separated into
separate files (as I have done with 'parent' and 'name').
Possible keys: type, desc, driver, irq, dma,
dma2, map, serial, uuid, (topology, location),
bus, ...
Note that I have categorized them as 'info'. Later
the devfsd2 _can_ but does not need to use them.
example1:
name: aix7xxx
type: scsi-host
desc: Adaptec AIC-7881U (rev 1)
irq: 11
example2:
name: colormap
type: fb-colormap
desc: Color map for framebuffer 0
[ parent is the main fb0 ]
/ioctls
Is a '\n' separated list of ioctl strings the
node supports. (And there could be dir
/proc/sys/ioctls/STRING describing it...)
/aliases (rw)
Initially empty, but writing into it strings
in format 'major:minor' makes kernel to redirect
requests into this device.
[ Actually, the next item should not be needed. I am only
keeping it, so I can say it really does not belong here... ]
/node
The node itself where open/read/write/ioctl can be done.
This should be 'ordinary' file not char/block dev as
it is virtual enough.
Now the devfsd2 part:
devfsd can operate 2 ways:
1) Tell devid to react to specific major:minor numbers
/dev can be then on disk, containing old-style major:minor
nodes.
2) Do a new-style mknod(2) (pathname, devid), after that
set perms. /dev should be managed by current devfs1 or
can be on ramfs... It should _not_ get into disk as
devid's can be different on next boot.
devfsd2 flowchart:
* start, read all current devices, attach to listening events,
read config.
* match devices, put them somewhere. Really unknown devices,
with even 'type' unknown should simply syslogged so admin
can give some rules for them.
Here will be the heuristic for device manipulation.
1) new-style: load config, try to match devices by whatever
rules are specified there. Eg. disk by this serial here,
mouse with that usb-location there... All stuff under
a framebuffer N goes to dir /dev/fbN/'name' where 'name'
is taken from /info ...
If not matched, then put to some default location for
that kinda device. Eg. unknown USB-mouse, put to next
free /dev/usbmouseX. Unknown ide1 slave disk, put as hdd.
2) devfs1-style: by current devfs1 rules.
3) old-skool (default?): tell device needed major:minor
from MAKEDEV database.
I guess initially some minimal implementation (the 3/MAKEDEV)
should be in kernel, when init/devfsd2 are more spread, then
it can be dropped from kernel.
All details like layout, filenames, keys, value formats
should be specified centrally, by some imortant person
(hpa/LANANA...)
Various notes:
* /devices/0 should be 'root', where all other can be attached.
* embedded devices: in-kernel defvsd can be dropped, as hardware
is fixed and known, init can run minimal program that does the
needed initialization, then exits.
* various other parts of kernel can refer to devid if needed.
eg. ioctl 'on what device this file resides'
* in-kernel code can open devices by devid, user only through
mknodded entries.
* devfsd2 config should be flexible enough to specify eg
'ide0 master partitions should named as hdaX'. So it
must be possible to match not only current devid info
but also parents'.
* permissions-should-be-on-disk: well, they are: in devfsd2
config file. Ofcourse the major:minor variant can be used.
If the major:minor size get increased, the devfsd2 should be
able to do fixed-dynamic allocation so admin can fill the /dev
with nodes and tell devfsd2 to give them out to specific types
of devices.
* eg. when fb0 is a device (not dir) in /dev then Linux VFS
allow use of sub-devices in form /dev/fb0/xxx. I personally
does not like it, but it is allowed in devfs2 too - the
available sub-devices can be described under devid in separate
entry.
Ofcourse, when they are some form of parameters for device
they they probably cannot be described so easily.
* Note that the devid numbering follows the detection order.
So if you have two same type devices, and no specific info
what to do with them, devfsd2 can be backwards-compatible
by assigning them in that order.
* As I said there are different info available for different
devices. So driver/subsystem maintainers with LANANA and
devfs2 maintainer should decide what info to put into /info
and also create needed devfsd2 config rules for both old-style
and new-style configurations.
* booting/mounting: I cant imagine this as impossible. kernel
mounts root, runs init, that mount devfs into /devices, ramfs
into /dev, runs devfsd /devices /dev.
So. Comments? How much of this is sane?
-- marko- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/