[ Sunday, January 30, 2000 ] Jamie Lokier wrote:
> On the negative side, there was this one time when another entry was
> deliberately added to the middle of file_operations. It broke every
> driver, but it forced (in theory) driver writers to consider whether
> they had to write code for the new function.
Having created the patch, I can confirm that the *vast* majority of
drivers hadn't updated with fasync and lock, but it didn't hurt their
functionality at all. Many drivers (if not most) are fine implementing
the file_operations entries they are filling right now (many only
implemented 2 or 3, but they were simple drivers and that was enough for
them). The fact that the patch has a 3:1 ratio between previous linecount
and new linecount shows on average only 1/3 of entries are used anyway.
While I can understand what you're saying, I still think the benefits
(listed in the post that started the thread) out-weigh this one possible
benefit, a rarely seen and dubious one.
The current method orders the functions in the structs based more on
historical actions rather than any real cache or performance benefits.
I'm just trying to add that flexibility as (inevitably) testing and
studying will show that internal data structure reconfiguration in the
kernel can yield possible performance benefits at zero cost ... but only
if our structs are flexible :)
James
-
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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:26 EST