introduction to netbsd kernel
DESCRIPTION
TRANSCRIPT
Introduction to the NetBSD kernel
Mahendra [email protected]://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 :