I would be interested in trying to lead a discussion of threading and SMP in a couple months time. Maybe after we've had at least one walkthrough in each of the mentioned areas:<br><br>> Scheduler<br>> Memory Management
<br>> File System<br>> Device Drivers<br>> Networking<br>> Boot / init<br>> Interrupt handling<br>> ipc<br>> system calls<br><br>I don't know much about threading and SMP in the kernel just yet, but I have been researching concurrency in languages for two years, so with enough time to prepare I'm sure I could lead a decent walkthrough.
<br><br>Any thoughts from the organizers? Paul? Perhaps we should start assembling a list of people who've volunteered to lead a session.<br><br>-Richard<br><br><div class="gmail_quote">On Nov 8, 2007 11:50 PM, Larry Colen <
<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Thu, Nov 08, 2007 at 11:49:13PM -0700, Kristian Erik Hermansen wrote:
<br># > Kernel debugging (gdb extensions?)<br>#<br># kdb + crash + serial console?<br><br>Ayup.<br><br>Back in 2000 I worked on a kernel hacking project where the other guy<br>on the project had added the serial console kernel debugging
<br>extensions. I didn't do it, so I didn't get the details, it just<br>magically worked for me.<br><br>One cool thing that I did, was do most of my debugging on a virtual<br>machine running under VMWare. I ran a cable from the host machine's
<br>serial port to the target machine's serial port.<br><br>It worked wonderfully. I could "checkpoint" my debugging<br>progress. Save state. And when the target crashed, I didn't crash my<br>dev box.<br>
<br># > When Paul asked for discussion topics, I suggest starting with high<br><div><div></div><div class="Wj3C7c"># > level structure. He asked me to layout what I consider to be the<br># > primary structural elements, so here's my quick and dirty outline. I
<br># > highly encourage people to post their suggestions as to a better list.<br># ><br># > Scheduler<br># > Memory Management<br># > File System<br># > Device Drivers<br># > Networking<br>
# > Boot / init<br># > Interrupt handling<br># > ipc<br># > system calls<br>#<br># * Protection and security mechanisms to protect against hostile local users?<br># * System calls and kernel interfaces?
<br># * Mechanisms to protect against syscall/kern proxying (interface<br># shims) by malicious code?<br># * Virtual computing and why Xen has been so intrusive (xen-patches in<br># mainline), while kvm is not (very few kvm patches)?
<br># * Threading implementation and issues?<br># * SMP details?<br># * Most efficient ways to debug OOPS and AIEEEEE!!! ??????<br># * 64-bit specific issues?<br># * Real-time kernel optimizations?<br># * How to slim the kernel for cell phones, mobiles devices, and embedded systems?
<br># * Micro-kernel versus macro-kernel :-)<br><br></div></div>A lot of these are good and useful things to know about. But, some of<br>them are esoteric, or specialized enough that we may want to hold off<br>going into details, unless we get someone who knows a lot about some
<br>of them who wants to volunteer to talk about them.<br><div class="Ih2E3d"><br><br>--<br> Too much of a good thing is better than too much of a bad thing.<br>Larry Colen <a href="mailto:email@example.com">
firstname.lastname@example.org</a> <a href="http://www.red4est.com/lrc" target="_blank">http://www.red4est.com/lrc</a><br><br><br>_______________________________________________<br></div><div><div></div><div class="Wj3C7c">svlug mailing list
<br><a href="mailto:email@example.com">firstname.lastname@example.org</a><br><a href="http://lists.svlug.org/lists/listinfo/svlug" target="_blank">http://lists.svlug.org/lists/listinfo/svlug</a><br></div></div></blockquote></div>