Recently I came across this comments in include/linux/kdev_t.h:
Inside the kernel, we aim for a kdev_t type that is a pointer
to a structure with information about the device (like major,
minor, size, blocksize, sectorsize, name, read-only flag,
struct file_operations etc.).
(...)
An obstacle to immediately using
typedef struct { ... (* lots of information *) } *kdev_t
is the case of mknod used to create a block device that the
kernel doesn't know about at present (but first learns about
when some module is inserted).
Within two weeks, this comment is about to celebrate its forth anniversary
and I'd like to know if there's still an aim for a kdev-struct. I'm
particularly interested as I'm currently working on per-device
i/o-statistics and per-device bdflush-params. Both times I basically run
into the same problem: I need a connection kdev <-> private struct
pointer. In general the pointer will be NULL indicating to take default
values.
With kdev_t being a struct I'd simply add a new member to it and do
typically something along
int my_ioctl(kdev_t dev, void *arg)
{
(...)
if(!dev->my_member)
do_default(...);
else do_sth_special(...);
(...)
}
while currently I have to provide a more or less clever lookup function to
do the transition. So I have to choose between wasting ridiculous amouts
of space in an array or being smart with hashes/lru lists etc., which all
have in common that the worst case is the common case (lookup fails, i. e.
use defaults).
Therefore I'd be glad if someone could comment on whether a structured
kdev_t is still a design goal. Or maybe you can even think of better
solutions to my problem?
Thanks,
Daniel.
-
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/