Technically it is. Any library or application can be implemented or ported into the kernel.
But what’s the upside? If the Allegro API were inside the kernel and the application that uses it outside, each call to Allegro would involve a syscall and context change, which is "expensive" (it takes longer than a normal function call).
It is possible that the performance will be much better with Allegro out of the kernel, in the same memory space as the game or app. Unless you play the game within the kernel as well, then it would actually be a regression to the time of MS-DOS where all the code has direct access to hardware all the time.
And as you may know, any bug in the code that’s inside the kernel makes the computer crash. Surely Allegro has bugs...
In the kernel there should only be code that needs full access to the hardware, and needs to have controlled access, either per user or per set of permissions.
It also ends up getting a lot of code in the kernel that, for pragmatic reasons, works faster if you’re there. This is the case for most device drivers, file systems, etc. Still there are many drivers that work in user mode, and there are cases even where user-mode is faster (for example if a single application makes use of a network card, the set gets faster if the application itself contains the driver of that card).
Get it. What do you recommend to implement images in the kernel? In case I think it is the first step to GUI development
– João Paulo
In fact, you’d have to choose the video driver architecture first. In a project I participated in ("your past condemns you!") using Linux framebuffer, whose driver is entirely inside the kernel, so it would be an option to make the Alegro framebuffer driver talk directly to the kernel driver without syscall.
– epx