Subject: install/10710: fdset can require switching floppies multiple times.
To: None <>
From: John Hawkinson <>
List: netbsd-bugs
Date: 07/29/2000 10:19:14
>Number:         10710
>Category:       install
>Synopsis:       fdset can require switching floppies multiple times.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    install-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 29 10:20:00 PDT 2000
>Originator:     John Hawkinson
>Release:        -current of 14 July 2000
System: NetBSD 1.5B NetBSD 1.5B (ZORKMID-$Revision: 1.16 $) #20: Fri Jul 28 20:08:34 EDT 2000 i386

	Booting a sufficiently large kernel in an fdset can cause multiple
floppy swaps. I.e.

boot off of floppy 1. It starts to read the first section, hits the end of
the floppy, and requests floppy 2. Insert floppy 2. It finishes reading
the section, and then asks for floppy 1 again. Insert floppy 1, it reads
another section, and asks for floppy 2. Insert floppy 2, booting completes.

This is undesirable. Ideally only 1 insertion of a given floppy should be

	Build a distrib/i386/floppies/fdset with CARDBUS rather than INSTALL.
	It seems like any complete solution involves mods to both exec_elf()
in /sys/lib/libsa/loadfile.c, as well as mods to the linker.

exec_elf() needs to read .shstrtab in order to find some sections (or it will
shortly, when .stab support is added to elf; that's pending on my part),
but .shstrtab is typically late in the kernel, at an offset like
0x4333bb. So if .shstrstab is ever needed to locate a section that is
on the first floppy, but it itself is on the second floppy, this
requires a swap.

So ideally the linker would place .shstrstab early in the image,
as well as the ehdr and the shdr. Then exec_elf() could determine in 
advance everything that needed to be loaded , and sort that by offset,
and then read in order, not requiring the swaps.

On the other hand, perhaps a linker script is not necessary, if
the sections that will be loaded based on .shstrtab are also on
disk 2, and .shstrtab is on disk 2. If so, then things would Just Work(tm),
as long as loadfile did the right sorting, or if the sections were ordered
such that that was unnecessary.

I don't particularly relish changing loadfile *again*, and am reluctant to
do it now, especailly as I have other pending loadfile changes.