Messages in this thread | | | Date | Tue, 27 Jul 1999 21:57:32 +0200 (CEST) | From | Daniel Kobras <> | Subject | kdev_t a struct? |
| |
Hi!
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/
| |