Introduction to the NetBSD kernelMahendra MMahendra_M@infosys.comhttp://www.infosys.comThis 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.RunQueue sched_qs Doubly linked lists of tasks Running Task 1 Task 2 ... Task N [Priority: 1] ... Sleep Task 1 Task 2 Task M [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
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 cant 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 Linuxs 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.
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. – Doesnt 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.
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