Introduction to NetBSD kernel

Introduction to the NetBSD kernel

Mahendra MMahendra_M@infosys.comhttp://www.infosys.com

This work is licensed under a Creative Commons Licensehttp://creativecommons.org/licenses/by-sa/2.5/

Agenda

A short introduction to NetBSD systems and some history Suitability for embedded systems Slight comparisons to Linux interspersed throughout – for

better understanding A look into various features NetBSD Capabilities !! Our focus will primarily be on NetBSD 2.0 series ( 3.0 was

released a few weeks back )

About NetBSD

A BSD “ distribution” targeted at portability. Includes a kernel, libraries, config tools, scripts and build

systems.– The BSD systems have had a history of around 25 years.

– Is under a BSD license.

OpenBSD was forked out of the NetBSD project. Not really meant for Desktop/Server purposes.

NetBSD – the basic stuff

Currently in version 3.0 ( released a few weeks back ) Highly portable – ports exist for a large number of

architectures and reference boards.– Portability has been a design goal right from the beginning

POSIX compliant Good VM, Networking, Threading subsystem Has withstood the test of time in the market Not as rapid a development model as Linux.

– Tends to let features stabilize on FreeBSD/OpenBSD and then pick it up :-)

Some good design decisions inside the kernel. Low memory footprint.

Process Scheduling

Time-sharing scheduler - based on multi-level feedback queues

Each task is placed in a priority based run-queue Each priority is time-sliced and scheduled in round-robin

fashion O(1) algorithm similar to Linux ( though not feature rich ) Has an interactivity estimation algorithm that recalculates a

process' priority Kernel pre-emption is not available No per-CPU runqueues No soft real time support available

– Commercial patches available for hard real time.

Approximate representation of scheduling.

Task 1 Task 2 Task N

Task 1 Task 2 Task M

RunQueue

Doubly linked lists of tasks

[Priority: 1]

[Priority: n]

......

hardclock() - Increments CPU utilization count per tick schedcpu() - adjusts CPU utilization once per second and

on 4 ticks invokes resetpriority() to recalculate a process' priority. Also increments sleep count of blocked processes

resetpriority() also checks for ready higher priority processes and schedules a context switch

Running

Sleep

sched_qs[]

Manipulating runqueue

void setrunqueue ( struct proc *p )

– set the specified process in the system run queue.

void remrunqueue ( struct proc *p )

– remove the process from the run queue

( struct proc * ) nextrunqueue( void )

– Returns the next process in run queue which can run.

The above functions have to be called with the lock held on the scheduler using SCHED_LOCK()

More functions available for controlling system scheduling priority levels.

SMP Support and re-entrancy

SMP Support – Not really critical in embedded systems – but is very highly

important in upcoming Telecom architectures which use multi-core CPUs etc.

– Currently being worked upon in NetBSD.

Still has a big (BAD) global kernel lock. Discussion going on in lock free data structures in NetBSD.

– They can't implement methods like RCU

Other general locking semantics available in the NetBSD kernel – slightly different in behaviour than Linux methods.

Lock Semantics

Simplelock – simple spinning mutex – for short critical sections of code ( SCHED_LOCK )

– Only lock that can be used inside an interrupt handler. ( Interrupt disabling/enables has to be done manually )

– ( struct simplelock )

Higher level lock for sleep/spinning is also available.– Provides exclusive and shared access locks.

– Provides recursive exclusive access locks within a thread.

– Allows upgrading/downgrading of shared access locks to exclusive locks and vice-versa.

– ( struct lock )

– lockinit() and lockmgr() functions used

– spinlockinit() and spinlockmgr()

Threading model

NetBSD kernel is thread aware and are POSIX compliant Supports a n:m model of threads using Scheduler

Activations Drastically different from Linux's approach.

– Supports 1:1 model of threading ( NPTL )

– The kernel does not distinguish between threads and processes

– A process is a group of thread ids – thats it.

– All threads in a process are visible as tasks to the kernel and active threads are allocated time-slices for scheduling.

– All active threads will get their time-slices

– Can set real time priorities to tasks.

– APIs are available for real time threads handling

Threading model ( contd .. ) NetBSD

– Treats threads (lwp) and processes differently

– Supports Scheduler Activations. m:n model of threading

– Not all threads are visible to the kernel scheduler. User space code takes part in telling the kernel which thread to schedule.

– The threads in a process have co-operative scheduling. A thread can keep running for most of the time – careful

programing required.

– Using special environment variables Round robin scheduling can be achieved.

Note : Today, Linux seems to have better thread/process creation, spawning and context switching times.

Threading model ( contd.. )

KQueue : Event notification mechanism

NetBSD supports a generic event notification framework – kqueues.

Excellent replacement for select() / poll() APIs.– No need to pass entire descriptor set to each call.

– On return, applications need not check all file descriptors for updates.

– Reduces data copying ( fd list from kernel to user space and vice-versa )

Can handle multiple types of events.– Signals, Vnode/Process monitoring, Timer events etc.

Can club multiple occurrences of an event into a single event New event types can be easily added. All with just two system calls !!

Debugging support and bootup NetBSD has much better debugging support.

– DDB – an in-kernel debugger

– Supports kernel crash dumps Dumps to swap partition on crash On reboot, retrieves the dump from swap to a specified location.

– Supports KGDB (source level debug) – remote debugging.

Boot up.– Doesn't support a self-extracting kernel

– The kernel is gzipped and given to the bootloader, which extracts it to memory and jumps to the start address.

– It can be easily added, if required.

Device support

Support is poor in NetBSD Flash devices ( MTD etc. ) are poorly supported. Supports a primitive mechanism of Ram disk ( MFS )

– Not memory efficient : tmpfs is being worked upon

– OpenSource implementations are not available. ( Commercial products are available )

– Results in considerable lead time in development.

For boot time, it allows embedding a file-system into the kernel

Build systems and configuration

Integrated build system.– The entire system : kernel, compilers and tools, libraries and

applications can be compiled ( native or cross platform ) using a single script – build.sh

– The same script can build distributions, tarballs, archives and can also update existing systems and install fresh systems.

– Adding new components to the build framework is extremely easy.

NetBSD provides an autoconf mechanism– Builds a device tree format which is extremely easy for getting

coded in and for device identification.

Some key aspects..

Very clean code. No warnings and errors during compilation Little support for loadable kernel modules – not

recommended. Development models is more “ cathedral” like !! Well documented but not easy to find answers. Commercial support is available. Many people do not contribute code changes back to the

NetBSD tree. ( BSD License ). Supports non-executable stack and heap ( on architectures

that support this ) Has support for Xen ( not really necessary for embedded

box but can be used for development boxes ).

Business related License (violation) is a serious cause of concern

– BSD License is very liberal

– One of the main reasons why telecom companies go for BSD – eg: Juniper ( JUNOS )

Protocol stacks and third party code– Are available usually for most BSDs.

– To be more portable, they tend to ignore benefits of one OS Eg : Making use of kqueue().

New device support– Vendors of new devices like Network Processors, etc. release

code only/mainly for Linux ( kernel modules etc. ).

– Extra effort is required in such cases to port things to NetBSD.

Links

Coming soon !!

Finally ...

Questions ?? Thanks to

– Organizers for giving me a chance to speak at GNUnify 2006

– NetBSD and Linux developers who helped me during my work

– To Infosys for sponsoring my visit to GNUnify 2006

Special thanks to YOU for listening...

You can contact me at :

Mahendra_M@infosys.com