i386 boot1.c peculiarity while studying code

["William D. Jones" <thor0505%comcast.net@localhost>]

Hello all,

Just for the sake of studying the source code, I'm looking over NetBSD's 
boot process for i386 (in sys/arch/i386/stand). So far I'm not having too 
much trouble, but one thing that is bothering me is the code that attempts 
to open() the boot directory.

From what I understand, pbr.S, label.S, bootxx.S, and boot1.c all get linked 
into a filesystem-dependent binary file that becomes the bootsector of a 
hard disk or a floppy drive; Sector 0 belongs to pbr.S (what the MBR code 
jumps to), Sector 1 belongs to label.S, and Sectors 2-15 belong to 
everything else. On line 59 of boot1.c, there is an open "system call". From 
what I can gather, this open function actually calls a dummy label in 
bootxx.S, after initial setup, that JMPs unconditionally to file system 
driver code in libsa. The filesystem driver actually loaded is based on 
Makefile defines, so multiple bootloaders are created based upon the 
kernel's destination filesystem.

However, boot1.c proper calls a wrapper function for open ob() three times: 
line 80, 90, and 106. The ob() wrapper takes no arguments, does not access 
global state, and hence open() always receives constant parameters "boot". 
Between the calls, some static (keyword!) data structures are manipulated to 
increment the sector at which to open the file. But since these data 
structures are static, I'm having trouble visualizing how the filesystem 
code eventually called by open() knows what region of the boot media to try 
next. It seems like all three calls are redundant, since there's no state 
changes that I'm aware of. So, does each call to open() actually check a 
different region (sector) of the boot media? Am I missing a piece of 
information or global state that libsa's filesystem drivers are aware of? 
I'm a bit hung up on this, and I'd appreciate any help someone who has 
worked with the i386 bootstrap code can give me!

Also, can someone confirm I understand the following correctly: libsa's file 
system code, at least for ufs/ffs, just blindly scans the disk after the 
bootsector until the superblock is found, and then assumes the first 
instance of a "boot" directory is the correct location to find the next code 
to load?


Sincerely,

--
William D. Jones