The MICRO kernel

pathiaki

pathiaki

Hi,

Is there any type of an initiative to have a small, compact kernel that has nothing but all the interconnects and infrastructure of the kernel in place? That is, anything that can be loaded by a "module" is completely removed and anything that has not been used in the last twenty years can be removed if you have "current" hardware?

Or, how about a script that does something really cool... parses the /var/run/dmesg.boot file for devices when you boot the GENERIC kernel and builds MICRO, a kernel config file with the basics and /boot/loader.conf.local with all the kernel loadable modules necessary for that platform.

Personally, I've been bitten by the GRAID issue, the "yenta" issue with the MFI driver, etc. This stuff is not necessary if your system does use it.
 
Sorry, I was trying to put in CODE and ended the message... *sigh*

Anyhow, MICRO might look like:

Code: 
cpu             HAMMER
ident           GENERIC

options         SCHED_ULE               # ULE scheduler
options         PREEMPTION              # Enable kernel thread preemption
options         INET                    # InterNETworking
options         INET6                   # IPv6 communications protocols
options         TCP_OFFLOAD             # TCP offload
options         SCTP                    # Stream Control Transmission Protocol
options         FFS                     # Berkeley Fast Filesystem
options         SOFTUPDATES             # Enable FFS soft updates support
options        UFS_ACL                 # Support for access control lists
options        UFS_DIRHASH             # Improve performance on big directories
options        UFS_GJOURNAL            # Enable gjournal-based UFS journaling
options         MD_ROOT                 # MD is a potential root device
options         MSDOSFS                 # MSDOS Filesystem
options         CD9660                  # ISO 9660 Filesystem
options         PROCFS                  # Process filesystem (requires PSEUDOFS)
options         PSEUDOFS                # Pseudo-filesystem framework
options         GEOM_PART_GPT           # GUID Partition Tables.
options         COMPAT_FREEBSD32        # Compatible with i386 binaries
options         HWPMC_HOOKS             # Necessary kernel hooks for hwpmc(4)
options         AUDIT                   # Security event auditing
options         MAC                     # TrustedBSD MAC Framework
options         SYSVSHM                 # SYSV-style shared memory
options         SYSVMSG                 # SYSV-style message queues
options         SYSVSEM                 # SYSV-style semaphores

# Make an SMP-capable kernel by default
options         SMP                     # Symmetric MultiProcessor Kernel

# CPU frequency control
device          cpufreq

# Bus support.
device          acpi
device          pci

# ATA controllers
device          ahci            # AHCI-compatible SATA controllers
options         ATA_CAM         # Handle legacy controllers with CAM
options         ATA_STATIC_ID   # Static device numbering

# ATA/SCSI peripherals
device          scbus           # SCSI bus (required for ATA/SCSI)
device          da              # Direct Access (disks)
#device         sa              # Sequential Access (tape etc)
device          cd              # CD
device          pass            # Passthrough device (direct ATA/SCSI access)
device          ses             # Enclosure Services (SES and SAF-TE)

# atkbdc0 controls both the keyboard and the PS/2 mouse
device          atkbdc          # AT keyboard controller
device          atkbd           # AT keyboard

device          vga             # VGA video card driver
options         VESA            # Add support for VESA BIOS Extensions (VBE)

# syscons is the default console driver, resembling an SCO console
device          sc
options         SC_PIXEL_MODE   # add support for the raster text mode

device          agp             # support several AGP chipsets

# PCCARD (PCMCIA) support
# PCMCIA and cardbus bridge support
device          cardbus         # CardBus (32-bit) bus

# Parallel port
device          ppc
device          ppbus           # Parallel port bus (required)

# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device          miibus          # MII bus support

# Wireless NIC cards
device          wlan            # 802.11 support
#options        IEEE80211_DEBUG # enable debug msgs
options         IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's
options         IEEE80211_SUPPORT_MESH  # enable 802.11s draft support
device          wlan_wep        # 802.11 WEP support
device          wlan_ccmp       # 802.11 CCMP support
device          wlan_tkip       # 802.11 TKIP support
device          wlan_amrr       # AMRR transmit rate control algorithm

# Pseudo devices.
device          loop            # Network loopback
device          random          # Entropy device
options         PADLOCK_RNG     # VIA Padlock RNG
options         RDRAND_RNG      # Intel Bull Mountain RNG
device          ether           # Ethernet support
device          vlan            # 802.1Q VLAN support
device          tun             # Packet tunnel.
device          pty             # BSD-style compatibility pseudo ttys
device          md              # Memory "disks"
device          gif             # IPv6 and IPv4 tunneling
device          faith           # IPv6-to-IPv4 relaying (translation)
device          firmware        # firmware assist module

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device          bpf             # Berkeley packet filter

# USB support
#options        USB_DEBUG       # enable debug msgs
device          uhci            # UHCI PCI->USB interface
device          ohci            # OHCI PCI->USB interface
device          ehci            # EHCI PCI->USB interface (USB 2.0)
device          xhci            # XHCI PCI->USB interface (USB 3.0)
device          usb             # USB Bus (required)
#device         udbp            # USB Double Bulk Pipe devices (needs netgraph)
device          uhid            # "Human Interface Devices"
device          ukbd            # Keyboard
device          ulpt            # Printer
device          umass           # Disks/Mass storage - Requires scbus and da
device          ums             # Mouse

That's about it for my kernel. I've actually left the FFS and UFS stuff in on this. The kernel I'm using doesn't even have that stuff as I'm using ZFS.

While we're on the subject, does anyone see anything else I can remove? Is there something that should be in that I've missed? Am I taking any kind of performance hit by loading modules of only the things I really need?

My loader.conf looks like this:

Code: 
# Kernel Tunables First
kern.ipc.shmmax=65536 
kern.ipc.semmni=512 
kern.ipc.semmns=1024 
kern.ipc.semume=40 
kern.ipc.semmnu=512 
kern.ipc.shm_use_phys=1 
kern.sched.preempt_thresh=224 

#Required modules for root file system booting and on zfs
opensolaris_load="YES" 
zfs_load="YES" 
vfs.root.mountfrom="zfs:zroot"
vfs.zfs.prefetch_disable="1" 
vfs.zfs.txg.timeout="5" 
vfs.zfs.arc_max="6144M" 
vm.kmem_size_max="8192M" 

# OS required modules 
aio_load="YES" 
accf_http_load="YES" 
cc_cubic_load="YES" 
ipmi_load="YES" 
mfi_load="YES"  
nullfs_load="YES" 
tmpfs_load="YES" 
if_em_load="YES"

So, what do you all think?

Thanks!

P.
 
throAU said:
See GNU Hurd.
Click to expand...

That is a completely different thing, so don't let us argue like Linus and Andrew. I will have a look at Hurd, when I have time. Retirement is only some decades away ;)
 
Please don't call your own kernel config GENERIC, change the ident line to MICRO:

Code: 
ident           MICRO

There's a different and usually better way to write kernel config(5) files that involves the use of the include directive. You include the GENERIC configuration file and disable the stuff that you don't want in your own configuration file by using nodevice/nooption directives. The upside of this approach is that when the GENERIC configuration changes your own custom configuration will pick up those changes as well. The downside is that if you want a really lean and mean kernel you'll have a long list of exclusions to list in your custom configuration file. The device driver and option names change extremely rarely so once you have excluded a driver you can trust that it will stay excluded. This is a snippet from my FIREWALL kernel configuration file for i386:

Code: 
ident FIREWALL
include GENERIC

nocpu   I486_CPU
nocpu   I586_CPU

nooptions   COMPAT_FREEBSD4
nooptions   COMPAT_FREEBSD5
nooptions   COMPAT_FREEBSD6
nooptions   COMPAT_FREEBSD7
nooptions   COMPAT_AOUT
nooptions   COMPAT_LINUX

nodevice eisa

option DDB

nodevice    fdc

nodevice    mvs
nodevice    siis
nooptions   GEOM_RAID
...

You can always check what drivers and options were included in the running kernel by examining the kern.conftxt sysctl(8) oid:

sysctl -n kern.conftxt

Be careful if you decide to strip all disk device drivers to modules, you'll have to then tell loader(8) in loader.conf(5) to load the disk driver modules or the system won't boot.
 
Yeah, the device driver modules are loaded into the same name/address space as the rest of kernel code making the kernel a monolithic one even if loadable modules are used.
 
Crivens said:
That is a completely different thing, so don't let us argue like Linus and Andrew.
I will have a look at Hurd, when I have time.
Click to expand...

I guess my point with that remark was that Hurd is an example of someone trying to do an open-source Microkernel. The resultant 20+ years of development for no usable end product is perhaps not what we want in FreeBSD :D

Crivens said:
Retirement is only some decades away ;)
Click to expand...

It might be in beta by then :)
 
throAU said:
I guess my point with that remark was that Hurd is an example of someone trying to do an open-source Microkernel. The resultant 20+ years of development for no usable end product is perhaps not what we want in FreeBSD :D
Click to expand...
Oh, there are several open source microkernels. But most are not really in use. One could argue that OS-X uses one of these, but there are a lot of others. The HURD has won the vaporware award for a long time, it simply does not offer anything right now that would be of benefit to the GNU users. As a developer, I see things a bit different. Developing a driver in a microkernel environment is really great, whereas doing so banging the metal is a bit more tricky. The ability to debug and single-step trough the code is absolute bliss.

It might be in beta by then :)
Click to expand...
The question is, will it come with Duke Nukem?
 
Crivens said:
As a developer, I see things a bit different. Developing a driver in a microkernel environment is really great, whereas doing so banging the metal is a bit more tricky. The ability to debug and single-step trough the code is absolute bliss.
Click to expand...
A microkernel has a few other benefits. A crashing driver for example won't take down the whole system, just that driver.

The question is, will it come with Duke Nukem?
Click to expand...
Well, it took a while but that got released eventually ;)

http://en.wikipedia.org/wiki/Duke_Nukem_Forever
 
kpa said:
Be careful if you decide to strip all disk device drivers to modules, you'll have to then tell loader(8) in loader.conf(5) to load the disk driver modules or the system won't boot.
Click to expand...

No, you actually want to load them after the kernel, it's much faster. Just use
Code: 
kld_list="sem aio acpi_ibm"

in /etc/rc.conf.

It works with most modules.
 
lme@ said:
No, you actually want to load them after the kernel, it's much faster. Just use
Code: 
kld_list="sem aio acpi_ibm"

in /etc/rc.conf.

It works with most modules.
Click to expand...

Thanks, I didn't know that. However, this setting won't work for modules that are required to mount the root filesystem?
 
kpa said:
Thanks, I didn't know that. However, this setting won't work for modules that are required to mount the root filesystem?
Click to expand...

Yes, but with all non boot-critical modules.
 
Sorry to necro this very old thread... but I have long dreamed of a world where we could delegate modules easily to userland “passing through” mappings of the Device memory and interrupts for the device using some generic construct... after playing with various hypervisors and IOV, a great toy should anyone have the time would be to use the bhyve VMM to provide micro kernel-like facilities in FreeBSD with VMM.

Granted I have not delved further than dream land into this, but one would think that a simple unikernel which provides the necessary library functions from the FreeBSD API for driver development and something similar to Mach’s shared memory model would suffice. If I only were still in university.

it would seem like this would be a performant and highly isolated way to handle the micro kernel approach. Since the API should be nearly identical to the actual Kernel, modules could be theoretically directly portable.One could even provide Linux native VMM instances or kernel modules without actually leveraging GNU licensed kernel code aka the Linux translation mechanism already provided in FreeB

anyways back to reality for me... just wanted to share some thoughts in case someone with more time were to want to run with it.

•edit• clarified a few vagarities
 
You must log in or register to reply here.
Back
Top