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.

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.

12. Threading model ( contd.. )

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.

19. Links
 Coming soon !!

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