| Age | Commit message (Collapse) | Author |
|---|
|
- cdev_get is only used in fs/char_dev.c; move it up, make it static and
unexport it.
- cdev_put is used in one more place (fs/file_table.c) but never in
modules; unexport it.
Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
To recap my argument: the current cdev implementation keeps an uncounted
reference to every cdev in cdev_map. Creators of cdevs must know to call
cdev_unmap() with the same arguments they passed to cdev_add() before
releasing the device, or that reference will remain and will oops the
kernel should user space attempt to open the (missing) device. It's an
easy mistake to make, and, IMO, entirely unnecessary; the cdev code should
be able to do its own bookkeeping.
|
|
new fields in struct inode - i_cdev and i_cindex. When we do open() on
a character device we cache result of cdev lookup in inode and put the
inode on a cyclic list anchored in cdev. If we already have that done,
we don't bother with any lookups. When inode disappears it's removed
from the list. When cdev gets unregistered we remove all cached
references to it (and remove such inodes from the list). cdev is held
until final fput() now.
|
|
New object: struct cdev. It contains a kobject, a pointer to
file_operations and a pointer to owner module. These guys have a search
structure of the same sort as gendisks and chrdev_open() picks
file_operations from them.
Intended use: embed such animal in driver-owned structure (e.g.
tty_driver) and register it as associated with given range of device
numbers. Generic code will do lookup for such object and use it for the
rest.
The behaviour of register_chrdev() is _not_ changed - it allocates
struct cdev and registers it; any old driver will work as if nothing had
changed.
On that stage we only use it during chrdev_open() to find
file_operations. Later it will be cached in inode->i_cdev (and index in
range - in inode->i_cindex) so that ->open() could get whatever objects
it wants directly without any special-cased lookups, etc.
|
