> The major number passed to the kernel is a product of a lot of > guesswork, because the loader has simply not enough information. I > have added a bit of code to my version of loader so you can use the > variable root_device_major_number to override the major number to be > passed to the kernel. I'm inclined to commit it, but I expect strong > objections from Mike, who wants the right thing done before we go > too far with these hacks.
Correct. I'm currently leaning heavily towards a tunable which can be set to explicitly control the device the root filesystem is loaded from, eg. set kern.rootdev.device=da0s1a However Justin's random number comment speaks back to a technique I was working on earlier, where such a number would be secreted in the disklabel of the disk to be booted. This number would have to be generated in a fairly unique fashion (I planned to use the TOD to try to keep it from wrapping), and it'd then be passed in in the environment or as an argument to the kernel. Bruce really doesn't like the environment, preferring instead arguments to modules. This breaks down as soon as you try to set things automatically (which module needs which arguments?) or load things automatically as a result of dependancies (how do you pass arguments to something that's loaded invisibly?). So in this case the code would set kern.rootdev.brand to the magic number, and the kernel would then search for it. However, there's another technique which would work quite well, and one I'm actually moderately enamoured of (modulo it's ability to confuse the heck out of people). Use the "last mounted on" field to find and mount filesystems. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
