rc.d script to load kernel modules

Doug Barton dougb at FreeBSD.org
Sun Jun 12 19:28:14 UTC 2011

On 6/12/2011 12:16 PM, Jason Hellenthal wrote:
> Doug,
> On Sun, Jun 12, 2011 at 12:00:56PM -0700, Doug Barton wrote:
>> Absolutely not. That would not fit into the way we do things at all, and
>> would essentially require /etc/rc to do the processing, which is a huge
>> step in the wrong direction.
> Ok can you explain this ? I am not seeing how /etc/rc would all of a
> sudden have to jump in to do the proccessing anymore than it would with
> the original patch ?

Ok, what do you propose the mechanism should be to process all of the 
*_load variables? And why do you think it's preferable to do it that way 
rather than simply listing the modules to load? (Other than, "that's the 
way it's done in loader.conf" which I don't think is important.) Oh, and 
btw, one benefit of the list (albeit a minor one) is being able to load 
them in order. An additional problem with *_load in rc.conf is that it 
prevents any other rc.d script from using ${name}_load as an option 
(which should be a hint as to another reason why this is a very bad idea).

> "That would not fit into the way we do things at all" funny because
> thats exactly how we have been doing things in loader.conf for some odd
> umpteen years plus. Unless I misunderstood how you meant this ?.

What do loader.conf and rc.conf have to do with one another? I'll save 
you the time, absolutely nothing (except ".conf" of course). They are 
completely different mechanisms processed by completely different back 

I'm actually not trying to be rude here, this is just such a terrible 
idea that I'm surprised someone as smart as you are suggested it. If 
this explanation isn't sufficient, feel free to submit a diff that 
implements your suggestion. Maybe working through it will make it more 


	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 freebsd-current mailing list