svn commit: r223917 - head/etc/rc.d

Doug Barton dougb at FreeBSD.org
Tue Jul 12 22:11:48 UTC 2011


On 07/12/2011 04:58, John Baldwin wrote:
> 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? 

Yes. r223732M

> 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.

No argument on module_path needing to be fixed.

>>> 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.

Ok, if it can be demonstrated that this bug in module_path is limited to
the specific, short window of 'from new boot loader till now' then I
don't mind simplifying the script after it's fixed.

Meanwhile, my point is that right now the script _is_ doing what is
supposed to be done, that's why I made the change. The fact that it has
to go through gymnastics to get to that point is a problem, and like I
said I'll be happy to revert the change if we can be sure that the
underlying problem is fixed. I'll definitely hold off on MFC'ing this
change till we get more information in any case.


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/



More information about the svn-src-head mailing list