Our customised Linux courses offer you the opportunity to share the knowledge of some of the foremost Linux specialists. Since every course is tailored to suit you and your company, this knowledge can be put straight to use in your organisation.
A course might, for instance, be scheduled as follows:
Day 1 – Application Development
- Makefile essentials, common variables and make functions
- Common GCC flags. What can you and what do you want to control?
- Introduction to Git and its open-source usage – a quick guide to the most important use cases.
- Set up a build system to build an entire environment automatically – and perhaps even auto-test parts of it.
- Various application-debugging techniques, including different ways of using GDB and front-end connections with Eclipse and how to debug embedded systems with limited resources.
- Workshop using examples taken from the presentation.
Day 2 (Morning) – the Linux Kernel
- How does Linux threading work? What does the kernel do when you thread your application? Are there different ways to thread your application?
- Schedulering: Linked to the section above on threading. How does the Linux kernel work? Which scheduling algorithms can be used? Which are preferred – and why?
Day 2 (Afternoon) – Linux Kernel Versions
- Linux kernel versions x.x and x.x
- What are the most important differences between x.x and x.x? Are there any major differences for developers as regards the two kernel versions?
- Porting between x.x and x.x
- Factors to consider when needing to port a driver between different kernel versions.
- How much work is it? What are the common pitfalls?
- Breakpoints in version x.x
- Porting a driver between different versions of x.x kernel.
Day 3 – Driver Development
- What form does a driver generally take? What should you think about when developing drivers? Includes examples of the different types of driver and how they talk to hardware.
- Kernel development
- How is kernel development different from development at the application level? What are the common pitfalls?
- Kernel debugging
- How do you debug the kernel itself when something has gone wrong – and how is this different from application-level debugging?