=== Kernel discussion ===
* Warren Toomey
Andy, I have a philosophical design question. VSTa uses the heap at boot time to allocate and initialise several data structure, including the GDT, the TSS etc. Why did you choose to dymanically allocate on the heap, instead of pre-allocating global data structures?
* Andy Valencia
Hi, back from a road trip. :-> I chose to use the heap when a data structure could be dynamically sized, or could be non-trivial in size.
For the latter, this was mostly caution concerning the various boot loaders I might need to live with as VSTa was ported about. Please
recall that VSTa first booted by being loaded from a 16-bit DOS app, and has also booted on Cisco routers.
* Warren Toomey
A while back I made noises about writing some notes on the VSTa microkernels. I'm teaching an OS course in a few weeks and I will try to use VSTa as the example OS for code reading. I'm going to try to get the students to write reports about sections of the kernel, and I've already started to make my own notes. Rather than fill the Wiki up here with questions, I've placed the drafts elsewhere: [http://minnie.tuhs.org/Vstabook/]. I'd love to get some feedback and also some answers to the questions in the notes.
* Warren Toomey
* If MALLOC() sleeps waiting for memory, then I assume it is a bad idea to be holding any spinlocks when attempting to use it?
* Right. Take care of your memory needs before grabbing spinlocks.
* Where in the system are ephemeral threads used? I've grepped through the srv/ code with no luck!
* Look in the C library. SIGALRM uses them, I believe. Perhaps also SIGCHLD.
* Andy Valencia
* MALLOC() returns void. Can it ever fail, and what happens if it does?
* It can't fail; you'll sleep for memory if there is none available.
* What are ephemeral threads?
* Threads which automatically die if all non-ephemeral threads die.
* Where is the idle stack, and how big is it?
* It's created in locore.s, 4k
* curthread = 0; Hmm, shouldn't 0 be NULL?
* Perhaps. 0 is certainly a legal pointer value, and its effects are just as portable as using NULL.
* In exit(), why the need to p_lock_void(&runq_lock, SPLHI); after we free curthread?
* You mean do_exit()? swtch() requires it on entry.
* Warren Toomey
Thanks for the offer Gavin! I think it'll be a few months before there is anything bootable, but I'll look forward to testing things on real hardware. I have also set up a Wiki page called ["Chat/Kernel/SMP"] for all the SMP-specific chat.
* Gavin Nicol
Most of the machines I own are dual-CPU boxes. If we want to get SMP shaken out, I have the hardware for it. I will be installing VSTa on a removable drive for one of these boxes in the next few days.
* Warren Toomey
I've started to write an ersatz Lions' Commentary on the 1.68 kernel. So far I've done tfork(), fork() and exit(). Some questions.
* MALLOC() returns void. Can it ever fail, and what happens if it does?
* What are ephemeral threads?
* Where is the idle stack, and how big is it?
* curthread = 0; Hmm, shouldn't 0 be NULL?
* In exit(), why the need to p_lock_void(&runq_lock, SPLHI); after we free curthread?
* Warren Toomey
Well, I teach OS, have contributed to Minix and written some kernel code for FreeBSD 1.x, but I've never dealt with SMP nor the Intel implementation before. But there's probably no better way to learn :-)
* Andy Valencia
The code to set up the application processors and SMP interrupt distribution
would need to be written. I probably found 90% of the SMP bugs when I enabled
kernel preemption, but there are doubtless still some really interesting bugs
to be found when you first bring up SMP. I would rate this as a pretty serious
first step into kernel work, although if you took it on and made it work you'd
come out of it with some excellent experience under your belt.
* Warren Toomey
Down below I asked if VSTa did SMP. Next question, has anybody tested it on a SMP x86 box? What still needs to be done? I'm going to play around with VTSa on Bochs (as I don't have any SMP hardware) and this might help me learn about the kernel. Any pointers to working SMP results, or things to do would be great.
* Erik Dalén
The sources in the "mach" directories are machine dependent, and the rest are portable.
* Andy Valencia
Yeah, Amiga dropped out when the guy who owned one stopped having time to pay attention. I thought briefly about keeping it alive,
but then the HW stopped being produced/supported, so I didn't pursue it. As far as MIPS, I did that port to a Cisco router, and
would have to spend time "sanitizing" the port to make sure it only had neutral MIPS code. This is not a great use of my time
unless somebody had a compelling MIPS-based project they'd like to pursue.
* James Haggerty
It looks like Amiga/68k stuff last came out with 1.5.2 (I noticed it a while ago after
seeing the reference in the FAQ once too often).
[ftp://ftp.zendo.com/vsta/vsta_152]
* Warren Toomey
Do you have any references to the MIPS or 68k ports? Would you be able to
give me a list of files in src/os/kern which are hw-dependent and which are
portable?
* Andy Valencia
There is only one data point WRT SMP, and that is that the kernel is
fully preemptive (the two problems are related). There is no doubt
more work to be done! There is a pretty clean demarcation between
HW and portable, enough that ports to MIPS and 68k went fine.
* Warren Toomey
Andy, how well does VSTa do SMP? I was thinking of taking the new
[http://l4ka.org/projects/pistachio/ Pistachio]
L4 microkernel and porting VSTa to run on top. Is there a clean division
between hardware-dependent and abstract in the areas of processes and memory
management?
* Andy Valencia
Hey, unlike almost every other system on the planet, the kernel has stayed pretty darn close to its
original 40k, even though all sorts of stuff like networking, distributed messaging, SCSI, and
new drivers have made the scene. I could've done worse, eh? :)