3 ms·
I was hoping this was going to be an analysis of design patterns used within the Linux kernel codebase itself, but the "everything is a file" concept is undoubt
by decasia 7y ago
I was hoping this was going to be an analysis of design patterns used within the Linux kernel codebase itself, but the "everything is a file" concept is undoubtedly worth talking about.
There could have been more discussion of the tradeoffs involved, though. The "file" abstraction doesn't seem to handle every kind of use case equally well.
- asveikau 7y agoHe hints at it when he shows the file_operations struct. Basically the way to achieve runtime polymorphism is to have function pointers in a struct. But you don't necessarily put the pointers in the per-instance struct. That would take memory proportional to the number of instances. So you create something like file_operations, which is nothing but pointers and no instance data. Maybe the ext4 driver declares exactly one of them as static const. And so every ext4 file gets the same function pointers. Another filesystem is free to provide their own. This arrangement is pretty similar to C++ vtables. Also note that some of the operations aren't unique to the filesystem. So ext4 points some function pointers at a generic implementation rather than a specific one. So these are some of the patterns discussed. I think it is just not exceptionally clear writing. (And I saw one spot where they got the syntax for pointers incorrect...)