Solaris Developer Chat Sessions

Print-friendly Version

Solaris Live Transcripts Index

December 19, 2000

Chat Title: Solaris Internals
Guest Speakers: Jim Mauro and Richard Mc Dougall

This is a moderated forum

LizA: Hello and welcome to Solaris Live! Our guests are Jim Mauro and Richard Mc Dougall, authors of "Solaris Internals Core Kernel Architecture". Jim, would you start off by telling us a little about yourself?

jim-mauro: Sure. I've been at Sun for about 9 years, working on SMP systems, clusters and enterprise architecture for the systems engineering field organization. I'm now working for Performance & Availability Engineering, working on enterprise systems availability and recovery.

arazo: Hello! I don't have your book yet. But I would have to ask you if drivers software behavior is widely explained.

Richard: Arazo, the book covers the kernel architecture, and discusses the thread model, virtual memory, file systems in detail. While we don't cover device drivers and I/O, it does work well as a complement to the existing device drivers developers guide.

LizA: Thanks Richard. We got you answering questions before you had a chance to introduce yourself.

Richard: Hi, I'm Richard Mc Dougall. I've been working at Sun for about 7 years, originally based in Australia. I am currently an engineer in Sun's Performance and Availability engineering group, in which we spend time analyzing Solaris and our key applications.

LizA: Thanks Richard. Would one of you give us an overview of what's in "Solaris Internals"?

jim-mauro: The book provides detailed information on the architecture of the kernel, with specific discussions on the multithreaded process model, the kernel dispatcher, the virtual memory system, file systems implementation, and some low level details on multiprocessor implementation, interrupts, etc. What was left out (conspicuously) was device I/O, networking and the kernel STREAMS Sun system. We left those items out largely because there's information on those Sun systems elsewhere (i.e. the Solaris documentation set), and the networking and STREAMS implementation is a HUGE topic, and would likely warrant a book just to cover those 2 topics.

LizA: Richard, people are going to ask, "What happened to Solaris 8?" Can you address that for us?

Richard: Good question - that was a very hard decision. We wanted this edition to cover Solaris 8, but we had to decide what was more important - to deliver the book this year, or to include Solaris 8 and deliver the book next year. We spent time talking with quite a few customers and developers, and given that nearly all of the material is relevant to both Solaris 7 and 8, we opted to deliver this year. We are still working on updated material for Solaris 8, which we hope to deliver in an updated edition.

LizA: After all the time you two spent writing this book, you must have an intimate knowledge of Solaris. In your opinion, what are Solaris' strongest features?

jim-mauro: IMHO, the features I find most compelling features to be multithreaded kernel. Some top-notch work went into the kernels synchronization primitives architecture, and the level of concurrency (fine grained threading) that yields excellent scalability on multiprocessor systems. Scheduling feature/realtime architecture. The process of providing support for realtime applications in the kernel result in some features applicable to other application classes. The flexibility of the kernel scheduling classes, in conjunction with features like user and kernel preemption and non-IPL driven synchronization all make for more scalable performance.

Richard: I would summize the majority of the features by one word - scalability. Solaris was designed with the key objective of scaling to a large number of CPUs. To accomplish this, the Solaris kernel implements symmetric multi processing, that is fully pre-emptive and uses fine grained locking around critical data structures. Other key features of the Solaris kernel are - It provides full 32 and 64 bit support, providing compatability with 32 bit applications.- It's portable across multiple platforms - i.e. x86- It's modular - and dynamically loadable - It supports multiple scheduler types- It supports multiple concurrent file system types- Processors can be grouped into processor sets- It provides a dynamic file system cache, which is self tuning- The I/O system is modular, allowing portability of drivers between systems with different bus hierarchies.

LizA: Jim, why does Solaris implement 2 threads libraries (Solaris threads and POSIX threads), and which should I use?

jim-mauro: There are indeed two sets of threads APIs in Solaris - Solaris threads and POSIX threads. Here's basically why... Solaris 2 began shipping about 8 years ago. A goal from the start was to provide a multithreaded kernel with support for multithreaded applications. In the early days of Solaris 2, the POSIX spec was not completed, thus it was not possible to write a POSIX compliant threads library. Thus, the Solaris threads library was developed so early adopters of Solaris 2.X could begin developing multithreaded programs. Once the POSIX threads spec was completed, and POSIX implementation was done and integrated. Both libraries remain to continue supporting those early applications written to the Solaris threads. For new developement, it's probably a good idea to use the POSIX interfaces for portability. Historically, we see a few more features going into the POSIX threads library versus Solaris.

arazo: Thank you for your reply. By the way, I am a PhD student. First of all, I want to know if it is possible to patch a memory image of a running process, in order to replace any SPARC-v9 instruction by a software trap instruction. (trap always, to ) Secondly, I want to know if it is possible to attach a trap handler to a software.

Richard: Great question! Alberto, yes it is possible. To overwrite the instructions in a running address space, the text portion needs to be remapped so it's writable. The debuggers do this via /proc - the source for gdb is a good place for an example. All of the trap handlers however are implemented in the trap table in the kernel - so you would want to do some kernel hacking to implement your own. Assuming this is for a project, and not for any customer oriented system. You could write a loadable module implementing your handler, and then write the address of your function into the trap table. You will however need to call a special function so that you can write to the trap table, since it's mapped read only you will induce a panic if you try and write to it directly.

LizA: What are the advantages of running a multithreaded process, versus running multiple processes?

jim-mauro: Traditional UNIX applications used multiple processes on multiprocessor systems to get concurrency. The introduction of threads libraries and APIs provide developers the ability to write multithread applications. The obvious advantages are the reduced kernel overhead - it's generally cheaper to maintain a large thread pool over a large process pool. Context switches between threads in the same process are faster than context switching across processes. This is due largely to threads in a process sharing much of the process context, including the process's address space. The sharing of other process-specific data, such as credentials and open files, and sometimes aid in the development of an app that requires shared resources. It should be noted that developing multithreaded applications that scale well is not always a trivial task. There are APIs for creating synchronization primitives for protecting shared data that must be used, and an eye must be kept on watching for potential "hotlocks" as a bottleneck.

LizA: Okay, in closing...the burning question on everybody's mind...why the Lotus engine on the book cover?

jim-mauro: Because it's much cooler than the engine in my 1995 GMC Jimmy!

Richard: Well, that's easy - we wanted something to give the image of "internals", and from there the rest was easy -). And the Lotus service manual just happened to be open to that page -)

LizA: Thanks to both of you for joining us today. We'll be back on January 11 with a chat on Solaris security.

Back to Top