![]() ![]() I experimented by creating a separate layer for the base layer of the drivers and I even moved some of the basic drivers such as 'char' and 'tty' and yet the coupling remained. Notice how even the 'drivers' are coupled to rest of the system. For instance, 'arch.arm' is so strongly coupled with 'kernel' that it is hard for developers to understand one without understanding the other. This also means is that the intent behind the decomposition has been lost. Indeed, in the Android kernel where nearly all the layers are coupled, developers may sometimes have to understand thousands of files to feel confident about their changes. In a coupled system developers need to understand both layers making the job of understanding the impact of change considerably harder. This partitioning algorithm reorders the subsystems based on dependencies, revealing what is "lower" and what is "higher." In an ideal implementation, the developers of the higher layer need only understand the API of the lower layers, while the developers of the lower layers need to worry about the higher layers only when an interface is affected. And, Linux has no real modularity mechanisms to verify or enforce modularityĪ few things become apparent after a partitioning algorithm is applied. For instance, C does not have the notion of an interface and so dependency inversion is not naturally supported (it is possible, however). Part of the problem is that that when Unix/Linux kernels were developed programming language support for modularity was poor. ![]() And yet, the Linux kernel itself has poor modularity. Application pipes were pioneered by Unix. The notion of device drivers that plug into an Operating System was popularized by Unix and is commonplace today. ![]() Let us also remember that many of the modularity mechanisms in use today were invented in Unix. Given its importance in the IT infrastructure of the world, that is just what one would hope. The resulting picture showed how coupled the Linux kernel is.įirst, let's acknowledge that the Linux kernel is well-written. And then there were issues dealing with how all the files were compiled, included and linked. To do this, it was necessary to figure out what files are included or excluded from the panda build. Our goal was to examine all the C/C++ source files that go in the panda configuration and to understand their inter-relationships. Armed with the Clang parser we felt confident and were pleased that we didn't run into any issues. But that difficulty just refers to the parser. Now we all know that C/C++ is a complex language and so we expect the analysis to be hard. So, our approach will work on any configuration of the generic Linux kernel, as well. The kernel code is written in C and it is derived from the Linux kernel. We selected the panda configuration for no particular reason - any other configuration would have worked just as well.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |