This document provides an introduction to the NetBSD kernel. It discusses NetBSD's history and focus on portability across architectures. Key features of the NetBSD kernel discussed include its process scheduling, SMP support, threading model using scheduler activations, and event notification using kqueues. Debugging support via DDB and KGDB is also summarized. The document provides a brief overview of NetBSD's build system and configuration, and notes some limitations in device support. It concludes by highlighting NetBSD's clean code, documentation, and commercial support options.
Factors to Consider When Choosing Accounts Payable Services Providers.pptx
Introduction to the NetBSD Kernel Under 40 Characters
1. Introduction to the NetBSD kernel
Mahendra M
Mahendra_M@infosys.com
http://www.infosys.com
This work is licensed under a Creative Commons License
http://creativecommons.org/licenses/by-sa/2.5/
2. 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 )
3. 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.
4. 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.
5. 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.
6. 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
7. 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.
8. 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.
9. 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()
10. 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
11. 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.
13. 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 !!
14. 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.
15. 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
16. 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.
17. 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 ).
18. 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.
20. 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