short answer: There is generic support already in the kernel. It’s up to the game controller MFG to use that standard. Also, the generic controller standard probably doesn’t support a lot of the new features, so it makes sense to have a driver to support the extra features of the controller.
Because Linux is a monolithic kernel. What that means, essentially, is that it contains all the drivers and everything else, unlike windows which uses a microkernel. The advantages of a monolithic kernel are, for instance, that you don’t need to install drivers manually, and you don’t have to depend on potentially malicious websites to host those drivers. Additionally, if any kernel ABI changes for one reason or the other, say there is a refactor to fix a vulnerability, whoever does the refactor would also refactor the driver code because that is in the kernel, and the kernel won’t compile if there’s an error in the drivers. This way, the driver is always updated, and you don’t have a situation where you have really old drivers that no longer work.
The disadvantage of a monolithic kernel is that there’s a lot more code that you have to take care of, and the kernel has a lot more responsibilities as opposed to a microkernel.
It’s not in the kernel. It just comes a long with the kernel. You can compile any of the drivers as modules. Back in the day when you had to fit your kernel and boot loader on a 1.44MB floppy. We would save space by compiling most of the drivers as modules and then they would get loaded into kernel space on boot. Now a days, a 100MB kernel is not a big deal when systems have Gigs of ram and harddrives are in the Terabytes. They keep the driver code with the kernel code mostly for the reasons that @dafta gave. When I was a Windows kernel dev for Intel, Microsoft did the same thing. That’s how you get inbox drivers. As a Windows kernel dev for Intel, it was our goal to get our drivers inbox’d with Microsoft so their developers would be responsible for maintaining the driver code, as well as testing, when ever there were changes to the Kernel that affected drivers.
short answer: There is generic support already in the kernel. It’s up to the game controller MFG to use that standard. Also, the generic controller standard probably doesn’t support a lot of the new features, so it makes sense to have a driver to support the extra features of the controller.
longer answer is way too long.
But why is it in the kernel?
Because Linux is a monolithic kernel. What that means, essentially, is that it contains all the drivers and everything else, unlike windows which uses a microkernel. The advantages of a monolithic kernel are, for instance, that you don’t need to install drivers manually, and you don’t have to depend on potentially malicious websites to host those drivers. Additionally, if any kernel ABI changes for one reason or the other, say there is a refactor to fix a vulnerability, whoever does the refactor would also refactor the driver code because that is in the kernel, and the kernel won’t compile if there’s an error in the drivers. This way, the driver is always updated, and you don’t have a situation where you have really old drivers that no longer work.
The disadvantage of a monolithic kernel is that there’s a lot more code that you have to take care of, and the kernel has a lot more responsibilities as opposed to a microkernel.
It’s not in the kernel. It just comes a long with the kernel. You can compile any of the drivers as modules. Back in the day when you had to fit your kernel and boot loader on a 1.44MB floppy. We would save space by compiling most of the drivers as modules and then they would get loaded into kernel space on boot. Now a days, a 100MB kernel is not a big deal when systems have Gigs of ram and harddrives are in the Terabytes. They keep the driver code with the kernel code mostly for the reasons that @dafta gave. When I was a Windows kernel dev for Intel, Microsoft did the same thing. That’s how you get inbox drivers. As a Windows kernel dev for Intel, it was our goal to get our drivers inbox’d with Microsoft so their developers would be responsible for maintaining the driver code, as well as testing, when ever there were changes to the Kernel that affected drivers.
Thank you for helping to clear that up.