Introduction to NetBSD kernel


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction to NetBSD kernel

  1. 1. Introduction to the NetBSD kernelMahendra MMahendra_M@infosys.comhttp://www.infosys.comThis work is licensed under a Creative Commons License
  2. 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. 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. 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. 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. 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. 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. 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 cant implement methods like RCU Other general locking semantics available in the NetBSD kernel – slightly different in behaviour than Linux methods.
  9. 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. 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 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
  11. 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. 12. Threading model ( contd.. )
  13. 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. 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. – 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.
  15. 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. 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 – – 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. 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. 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. 19. Links Coming soon !!
  20. 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 :