[svlug] Code walkthrough notes - boot
reiber at gmail.com
Sun Nov 25 23:54:57 PST 2007
Alvin - Thanks for helping flesh out all of this with Larry.
I hope you're OK with our adapting and using some of this on
...that's the wiki space associated with our every-tuesday kernel walk-thru's.
Regarding the servers and ops and such - I think we have things under control
but if we're in need of help I know where to find you.
Best regards, hope to see you again sometime soon.
On Nov 9, 2007 6:32 PM, Alvin Oga <alvin at mail.linux-consulting.com> wrote:
> i think that everybody has a different ideas and background
> of what they might want out of these "kernel hacking"
> - some might know assembly language
> - some might know C
> - some might not know how to compile a kernel
> - some might not know how to use an IDE
> ... endless variations with more people involved ..
> larry previously posted a very good starting point of topics
> to start with
> larry> Scheduler
> larry> Memory Management
> larry> File System
> larry> Device Drivers
> larry> Networking
> larry> Boot / init
> larry> Interrupt handling
> larry> ipc
> larry> system calls
> i'd add:
> rtc ( ticks )
> real time OS
> virtual and protected mode
> basic memory allocation tables and jump tables
> modular kernels vs monolithic kernels vs rt kernels and other foo-bar kernels
> writing a simple device driver ... will also teach you tons
> of info ...
> <device driver class 1>
> a device driver to read a 4x4 key pad and turn on and off the leds
> </class 1>
> if you're hard core ...
> write a newer/better "bios" :-) ... that is fun up to a point
> > >> One idea that someone mentioned to me was that we could have one
> > >> meeting where a specific kernel topic was presented and homework
> > >> assigned. Then the next few meetings after that would be follow ups to
> > >> cover additional details, time for discussions, question and answer
> > >> sessions, help with homework, etc.
> homework would be essential in order to learn ... but
> some folks learn by reading, some folks learn by doing,
> some folks learn by listening/watching,
> some folks learn by "fighting with the code" to pound it into shape
> what do you do with the folks that get frustrated that starts
> to fall behind the rest of the class for n-tuple reasons like
> xmas, family, work, doesn't know foo-bar tools
> > > So here's an idea. Lots of people seem interested in the boot
> > > process (me too). In 220.127.116.11, I see a directory at the top level
> > > called init.
> the boot process is or the questions one should be able to answer is:
> - what is an MBR, how many "BR" are there
> - what is the concents of the MBR
> - where is the partitions defined
> - what is a physical partition
> - what is a logical partition
> - what is a bootable partition .. how do you know it is bootable ...
> - what is stage1, stage2, ... and what is it doing
> - how much memory or disk space is associated with each stage
> - the kernel's "/init" is NOT involved in the boot process until
> way way way later, a few hundred thousand (?) assembly language
> instructions later
> - is /boot required to boot ?
> - is /boot required in the rootfs ?
> - what files, commands and libs is required in any rootfs ?
> - what exactly is the contents of initrd.gz .. why is it so ??
> - what is pivot_root .. why do you need it or its equivalent
> - is /initrd required ?
> - what is /linuxrc
> - what is a (boot) loader ...
> - what is lilo .. what is grub ... what is foo-lesser-known-stuff
> - why does grub need stage1.5
> - if you can make a bootable CF or bootable usb-stick or bootable cdrom
> where the OS ( linux, freebsd, dos, .. ) runs in memory
> than i'd say you understand the 'booting process" and "os"
> if it runs in memory, you can remove it the system will keep working
> making a bootable initrd or rootfs image is a good homework exercise
> however it does NOT require any kernel knowledge
> - however, that could be 1hr or 1 day or 1 week or 1month tasks
> for some detailed collection of "boot process" info
> than we can change gears and do the same "interview" for FreeBSD flavors
More information about the svlug