4 ms·

You can have libraries that can implement device driver functionality and talk directly to devices. Actually there are some (DPDK - Data Plane Development Kit a

You can have libraries that can implement device driver functionality and talk directly to devices. Actually there are some (DPDK - Data Plane Development Kit and SPDK - Storage Performance Development Kit, for example). > The scope of "everything that is needed to run" is a lot higher than might appear Having written one algotrading framework with full kernel bypass which required me to account for every single piece of kernel functionality in use by the application (mostly to eliminate its use) I actually think it is the opposite. Most applications do not need a lot from the kernel to function and what they are using could be supplied as library. Main reasons to have kernel -- protect shared resources and impose security constraints -- are not present when you intend to only have one application in the system.

eyberg 5y ago
Whether code is packaged a a library or inside a base kernel is definitely open to interpretation/design. We, for instance have the concept of a 'klib' which is code we don't want packaged in the base kernel but is optional and can be included at build-time. For instance deploying to Azure requires a cloud-init call to check-in to the meta-data server to tell it the instance has booted - not something you want to put inside every image if you are only deploying to say Google Cloud. Likewise, we have another klib that provides APM functionality but checks-in to a proprietary server so clearly not everyone wants that inside their image either. However, there is a lot more than just networking/storage drivers and some of it is very common code. Page table management for instance. Do you have 2,3,4 page table levels? How do you allocate memory to the app? IOAPIC vs PIC? Do you support calls the way GLIBC wants? RTC vs TSC vs PIT? I'm not saying any of these can't be librarized but they are most definitely not choices I would expose to the vast majority of end-users to choose at build-time for.

eyberg 5y ago

Whether code is packaged a a library or inside a base kernel is definitely open to interpretation/design. We, for instance have the concept of a 'klib' which is code we don't want packaged in the base kernel but is optional and can be included at build-time. For instance deploying to Azure requires a cloud-init call to check-in to the meta-data server to tell it the instance has booted - not something you want to put inside every image if you are only deploying to say Google Cloud. Likewise, we have another klib that provides APM functionality but checks-in to a proprietary server so clearly not everyone wants that inside their image either. However, there is a lot more than just networking/storage drivers and some of it is very common code. Page table management for instance. Do you have 2,3,4 page table levels? How do you allocate memory to the app? IOAPIC vs PIC? Do you support calls the way GLIBC wants? RTC vs TSC vs PIT? I'm not saying any of these can't be librarized but they are most definitely not choices I would expose to the vast majority of end-users to choose at build-time for.