Often we try and remain very focused on our goals and work hard to avoid distractions. Keeping a very narrow vision on our target can help shepherd a product to completion on schedule, a goal very important both to project managers and the engineers tasked with the work. However, it can also become tunnel vision and lead to unnecessary work, delays, and failed deadlines and ultimately a weak product.
The more you understand about the Linux kernel as a whole, the better you can work on its individual components, including device drivers. Normally device drivers do not (and should not) explicitly address (much less modify or control) global kernel issues such as scheduling and memory management. However, a badly written driver can certainly sabotage a lot of good work done in these kernel arenas, disrupting performance, wasting memory, etc, and at the same time deliver weak fulfillment of its mandated device service.
This is what I mean by "Largeness of Mind" in this context; the more you know, the better kernel citizen you can be and better the results that can be obtained.
If you have both extensive and deep knowledge of kernel architecture, facilities, APIs and methods, you are better armed to take advantage of them. I often see drivers that go to great lengths to accomplish something when there are already built-in facilities and API's that could have been used instead. Reusing the existing code and methods typically leads to code that has already been well debugged and is easier to get accepted upstream.
Unfortunately, a little bit of knowledge can sometimes be a bad thing. A well known and thorny problem is that there is a significant body of code in the Linux kernel that would never be accepted if it were submitted for upstream inclusion today. But the code works and (particularly if it is in device drivers for hardware that is well debugged and not changing) the incentive to rewrite the code is small. Relative newcomers to the Linux kernel development community are not well situated to sniff out these instances and can get burned when submitting code that reuses sub-optimal old code. There's no easy remedy for this other than taking a deep breath, learning more, and paying attention while lurking on kernel mailing lists. This conundrum is really a sign of the great strides forward the kernel has taken, rather than a reflection of a weakness.
Another reason to broaden the scope of your Linux concentration beyond immediate requirements is to garner respect and familiarity within the kernel development community. If you have been donating your skill and experience in areas which you don't have a direct commercial stake (and the sign of your contribution is positive!) you are likely to get more help on code areas that are more directly vital to your mission.
The Linux Foundation training program is partially designed to bring this broader picture to those who attend its classes. We take our students along a glide path to becoming members of the community, who know how to intelligently use the work of many others as well as make positive contributions themselves.
Sometimes class participants come to class with a particular problem to solve; they are looking for a "silver bullet" and hope to find it in the training. Of course, we are very happy when they succeed in doing that, and I might add that as often as not, the solution may be provided by another class participant rather than the instructor. But, such cases are incidental to our mission and can get in the way of delivering the broader purposes of the training.
Often, we have discussions with companies that are either considering obtaining Linux training, or have already committed to do so, about customizing the training (either streamlining or broadening, sometimes both) to more directly target the needs of the engineering team. Occasionally, we have to recommend that areas that we are asked to leave out be incorporated even if they are not directly related to the task at hand, because understanding them sets a framework for the end goal. To give an example we have had people taking Linux device driver training ask us not discuss PCI drivers and focus on platform drivers instead. This really doesn't make sense as the time savings are small and one can not fully understand how Linux deals with different bus architectures by studying only one.
Making the investment in time and brain effort to learn more about overall architecture and delving deeper into the underlying theory may seem wasteful at first glance. But in the long run, it is cheaper to do better, more well-founded work. And in many cases, it is even profitable in the short run if it helps avoid blind alleys and failed attempts to solve problems.