svn commit: r223917 - head/etc/rc.d
John Baldwin
jhb at freebsd.org
Tue Jul 12 19:46:11 UTC 2011
On Monday, July 11, 2011 8:13:19 pm Doug Barton wrote:
> On 07/11/2011 08:14, John Baldwin wrote:
> > On Sunday, July 10, 2011 8:53:31 pm Doug Barton wrote:
> >> On 07/10/2011 17:42, Pan Tsu wrote:
> >>> Doug Barton <dougb at FreeBSD.org> writes:
> >>>
> >>> Doesn't /boot/support.4th already populates kern.module_path with
> >>> the path of successfully booted kernel? How is this different?
> >>
> >> When you test it, what happens?
> >
> > If you do 'boot foo' at the loader prompt you get
> > /boot/foo;/boot/kernel;/boot/modules.
>
> No, I don't actually, which was my point to Pan:
>
> sysctl kern.bootfile
> kern.bootfile: /boot/kernel.patched/kernel
>
> sysctl kern.module_path
> kern.module_path: /boot/kernel;/boot/modules;/usr/local/modules
>
> That was after hitting "2. Escape to the loader prompt" at the beastie
> menu, and typing 'boot kernel.patched'. The fact that it did not work as
> one might expect was the reason I wrote the code that I did.
Is this on HEAD? Perhaps the new boot loader menus recently imported
broke this.
> > It is arguably broken that the old /boot/kernel is still in the list, but that
> > bug should be fixed in the loader, not here.
>
> I think that given the fact that we seem to have multiple broken
> versions (as in, my version is broken one way, yours seems to be broken
> a different way), it's hard for me to imagine removing the "belt and
> suspenders" that I've already added. Not to mention the need to support
> RELENG[78].
Well, I am basing off the behavior that the boot loader has had from 5.x up
through 8.x. It may be that the new stuff aded to 9 last month by Julian
broke this.
> > However, I've never had a
> > problem with kldload doing the wrong thing when using 'boot foo'. Do you have
> > an actual use case that is broken?
>
> I was initially hoping to avoid the gymnastics, but given that
> module_path wasn't doing TRT I thought it safe to err on the side of
> caution.
No, I think module_path should be fixed instead as if module_path is broken then
'kldload foo' at a prompt is also going to do the wrong thing.
> > Oh, and if you use 'nextboot -k foo' or set 'kernel=foo' in loader.conf then
> > it will DTRT. However, I would expect this script to be equivalent to a for
> > loop of 'kldload foo', but now it isn't since you are using a divergent
> > algorithm. That violates POLA IMO.
>
> It's not clear to me how what I'm doing is different than what _should_
> be happening. If you can spell that out to me I'd really appreciate it.
If you do 'boot kernel.foo', then /boot/kernel.foo/ should be in the module_path
which is what the kernel linker (when it autoloads a module on demand such as a
firmware image or filesystem module) and kldload both use to locate klds. All
of our various ways of loading a KLD should be following the same approach to
avoid confusion, and using module_path does work fine on at least <= 8.
It may be that there is a bug in the new boot loader stuff in 9 in which case that
is what needs to be fixed as if module_path is broken, kldload and the kernel
linker are also going to be broken.
--
John Baldwin
More information about the svn-src-head
mailing list