> > Since it looks doubtful that devfs will get applied anytime soon, do
> > you have an alternate solution to suggest?
>
> No. Unless you store the fops with the inode, you don't have much
> choice but to do a table lookup. So far it hasn't hurt us because the
> lookup is an index operation, which is fast.
However open(2) is not an index operation, even on devfs. Having a hash on
a kdev_t behind it ain't so bad. Since we'll eventually need more device
address space, and _mandatory_ devfs will almost certainly not happen,
some scheme other than direct mapping needs to be created.
My resource tree based approach is slower than hashes, but with some
tricks like making trees balance, it can be made at least O(log n) where n
is the number of unique device types.
I suspect we can have open() cache fops in struct inode if we decide it's
a big deal. I can't think of an instance where you'd have two sets of fops
on one file.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- 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/