No, it's not that critical for most uses. But it is extending the
path, which is generally a bad idea (I believe people often use the
word "bloat" for that). And who knows if someone out there *is* doing
open()s and close(s) rapidly for some special device?
> 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.
The mere fact that there is a table lookup required in the first place
suggests to me that the basic design may be flawed. Obviously, in some
cases lookups can't be avoided (for example finding the socket for an
incoming IP packet), but devfs shows that there is a clean way to
avoid that lookup. So the question must be asked: is the existing
approach the best way?
Like I said, so far it hasn't hurt us, but your patch (reasonable in a
devfs-less system with large majors) is increasing the penalty.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/