lkml.org 
[lkml]   [1999]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] dynamic char and block devices
On Wed, 13 Oct 1999, Richard Gooch wrote:

> > 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:3.172 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site