Hi Al,
It would appear that you have an idea, a vision, for how device
naming/access *should* work. You have talked about some aspects of
this in recent Email converstations, but I feel there are a number of
details that need to be clarified before I or others can have an
informed response to it.
So, could you please comment on the following points which cover most
of what I have gleaned so far of your ideas.
1/ You would like each device driver to provide a "mini" filesystem
which provides for all user-space access to the device driver.
Is this
a/ one filesystem which will contain an "instance" directory for
each device controlled by the driver or
b/ one filesystem type for which a different instance can be
mounted for each different device controlled by the driver.
I suspect a/ but in case it is b/, how would user-space get a list
of instances that can be mounted?
2/ This filesystem would contain
- files which can be read or, in some cases, written to
view/modify configuration info, similar to one use of /proc
- character/block special devices to provide normal access to
the device. The major/minor numbers would have no implied
meaning, and would probably be allocated from a large pool.
They would not be stable across reboot (is this correct?)
- directories to give structure to the information as
appropriate for the device.
3/ This scheme does not directly allow for (the kernel to provide)
arbitrily ordered sequential naming of similar devices
(e.g. disk/1 disk/2 disk/3 ...) as is sometimes useful.
Your opinion is that this is purely a user-space issue (and
after all, it involves imposing an ordering which is policy).
4/ You have suggested (I think) that like devices could be grouped
together using the "union-mount" feature of a plan-9 like
"bind".
However, doing a union-mount implies some sort of name-space
co-ordination, and you have explicitly said that you don't like
name-space co-ordination between device drivers.
So it seems to me that union-mounting has no real place in
tying device filesystems together. Is that right?
5/ All configuration for a device driver, including default
permissions, should live in simple text files, presumably processed
by some startup script or daemon.
This was one weakness in my devlinks idea. It made a special
case of configuring access control, separately from configuring
other aspects of a device. I haven't decided yet whether I
think they should be separate, but I lean toward uniformity.
6/ There would be a number of cases where separate drivers support
similar devices, and so should provide a similar appearance in
the device file system. A good example is SCSI controlers.
There are plenty of others.
My guess is that you would have this similarity provided by
library routines.
For example, the scsi mid-layer would have a number of
routines which a scsi device driver would call to populate part
of its file system. Is this correct?
7/ Assuming that I am right for (6), we now have the situation
where, considering the whole device filesystem namespace, some
parts of it are separate filesystems, and some parts are just
separate directories provided by libraries in other modules.
How do we decide when some subset of the device namespace should
be a separate filesystem, and when it should be a separate
library providing a subdirectory.
You made a point once about a filesystem being easy to remove as
a whole (unmount) where as de-populating part of a tree if a lot
more messy. I think this is a good point. However I am not
sure how to apply it. Two thoughts come to mind.
1/ we need to unmount the device filesystem when we unload a
loadable module (rmmod).
2/ we need to unmount the device filesystem when a device is
de-configured - probably due to hot-remove.
However, each of these is potentially multi-level (hot-plug scsi
controller with hot-plug discs, multi-level module dependancies)
and yet your approach, as I perceive it, has a single level -
mini-filesystems.
Could you point out where I have missed the mark?
Thanks,
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:22 EST