> > Incidentally, while I'm in there and thinking about it, I'd quite > > like to fix the boot code to boot from LS-120 drives at the same > > time. So if anyone has one of these, and wouldn't mind spending > > some time running a few bits of test code, I'd appreciate it. > > I have a ZIP if that can help you ??
Thanks. AFAIK, the essential difference is that the LS-120 needs to be treated (in the boot code) like a floppy, whereas the ZIP should be treated like a hard disk. But we need to accommodate both, so I'd be glad if you'd test the changes, once I've done them. > > #ifdef FORCE_FOO > > if (foo == 0) > > foo = 30; > > #endif > > Well, that breaks somewhere else, as the mount code is clever enough > to look at the name of the driver in this case "ad" which doesn't > match the specified #0 ie "wd". > I kindof tried this by having my driver put itself in both the > wd & ad majors in the table, but that doesn't work, because the mount > stuff gets confused on the root name somehow, and fails to mount > root because the names dont match... The arguments passed from the boot code to the kernel are howto, bootdev, res1, res2, res3, bootinfop where "howto" is an int containing RB_* bitflags (sys/reboot.h) which represent the boot options like -c, -v, etc. "bootdev" is an int put together using the MAKEBOOTDEV macro (sys/reboot.h) from the major#, unit#, slice#, and partition# of the boot device. "res1" through "res3" are reserved/ignored. "bootinfop" is a pointer to a bootinfo structure (machine/bootinfo.h) which contains an assortments of parameters, but none relating directly to the boot device driver (bi_bios_dev is for /boot/loader's benefit). So the *only* relevant info passed by the boot code is the major#. And if we force a change in the major# (for the sake of discussion, in the section of src/sys/i386/i386/locore.s that already has compatibility code for dealing with legacy bootblocks -- though I'm not saying that is the best place for it), we've done all we *can* do in the boot code, within the framework as it exists. So whether we add {"da", 30} to a lookup table in boot2, or use the FORCE_FOO approach, the results will be identical. > At any rate, any solution that makes it possible to boot with > a new driver without me having to call it "wd" something all > over the place is acceptable to me... Anyway, I take a look at both approaches, probably later today, and send you some diffs, hopefully relating to each way of doing things. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message