You can learn big systems by tearing it down to subsystems, and learning them one-by-one, the same way how you would split a big implementation (waterfall) into small steps (agile).
Here is a concrete example how I learned Kubernetes:
1. I tried to get an overall sense of what is it:
"Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications." - Ok that makes sense, but don't know what big part is it made from.
2. What problems does it solve and why? what are all the solutions? What features does it have?
3. What is the overall architecture? What parts does it have? API server, scheduler, controller managers, etc...
4. I installed it so I had to learn networking. What is a network plugin? How do they work? Learned most things which needed to running them.
5. What is the structure of it's API? You don't need to go into great details, just to see the big picture, like main api endpoints: /api/v1, /healthz, /logs, etc, etc...
6. Kubernetes Objects model high level overview. What are objects in Kubernetes? What Fields do they have? What are Controllers, Pods, Labels, Deployments, etc.
7. Authentication. How does it work, what methods does it have?
8. Services
9. ...
And so on. So basically you take ONCE concept at once and read everything until you feel you got the thing. For example, if you already understand the overall concepts, you can dive into what a Pod is by reading the article about it. I usually try to read the minimum number of manual PAGES until I confidentially grasp the entire concept I want to learn about.
By splitting huge and complex systems into small subsystems like this, you can become productive much sooner. Don't try to understand the whole thing at once.
You said you want to learn "kernel development". That's not gonna work, because the kernel itself consist of I don't know, thousands? of subsystems. So try to get an overall feeling. What are those subsystems? How can you split them into easy-to-digest parts? What is a driver? What parts does it have? What data structures are in the kernel?
So if you try to learn "kernel development" from day one and learn "kernel development" until you can "develop for kernel", it won't work. First, you need to know what you don't know. :)
Here is a concrete example how I learned Kubernetes:
1. I tried to get an overall sense of what is it: "Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications." - Ok that makes sense, but don't know what big part is it made from.
2. What problems does it solve and why? what are all the solutions? What features does it have?
3. What is the overall architecture? What parts does it have? API server, scheduler, controller managers, etc...
4. I installed it so I had to learn networking. What is a network plugin? How do they work? Learned most things which needed to running them.
5. What is the structure of it's API? You don't need to go into great details, just to see the big picture, like main api endpoints: /api/v1, /healthz, /logs, etc, etc...
6. Kubernetes Objects model high level overview. What are objects in Kubernetes? What Fields do they have? What are Controllers, Pods, Labels, Deployments, etc.
7. Authentication. How does it work, what methods does it have?
8. Services
9. ...
And so on. So basically you take ONCE concept at once and read everything until you feel you got the thing. For example, if you already understand the overall concepts, you can dive into what a Pod is by reading the article about it. I usually try to read the minimum number of manual PAGES until I confidentially grasp the entire concept I want to learn about.
By splitting huge and complex systems into small subsystems like this, you can become productive much sooner. Don't try to understand the whole thing at once.
You said you want to learn "kernel development". That's not gonna work, because the kernel itself consist of I don't know, thousands? of subsystems. So try to get an overall feeling. What are those subsystems? How can you split them into easy-to-digest parts? What is a driver? What parts does it have? What data structures are in the kernel? So if you try to learn "kernel development" from day one and learn "kernel development" until you can "develop for kernel", it won't work. First, you need to know what you don't know. :)
This is to verbose, but hope it helps.