usb modems and com devices into GENERIC

Gary Palmer gpalmer at freebsd.org
Thu Jan 4 11:25:08 PST 2007


On Thu, Jan 04, 2007 at 11:21:01AM -0500, John Baldwin wrote:
> On Wednesday 03 January 2007 15:58, Ulrich Spoerlein wrote:
> > M. Warner Losh wrote:
> > > I'd like to place the following in GENERIC.  We're getting more and
> > > more questions about these devices that we wouldn't be getting if we
> > > had them compiled in by default.  The really imporant ones are marked
> > > with a '*' below
> > > 
> > > device		ucom		# *
> > > device		umodem		# *
> > > device		umct
> > > device		uark
> > > device		ubsa
> > > device		ubser
> > > device		uftdi		# *
> > > device		uplcom		# *
> > > device		uvisor
> > > device		uvscom
> > > 
> > > the cost isn's so much, and we can filter them out from the
> > > installation kernel if size is an issue.
> > > 
> > > Comments?
> > 
> > Hi Warner,
> > 
> > why not do it the other way round? Keep them out of GENERIC, but have
> > loader(8) load some of the most used modules (snd_driver!) per default.
> > 
> > That way, people can easily disable these (without needing to
> > recompile).
> > 
> > I mean, what point is there in the whole KLD infrastructure, if we are
> > going to add every device into GENERIC anyway?
> 
> It works great when you are developing a driver that lives in a module. :)
> The point is to give people tools to use, it's up to different people to
> use them as they see fit.  I pretty much never use kernel modules (except
> for either working on a driver or test modules I write) but use static
> kernels since kernel debugging tends to be simpler when you avoid modules.
> It can also be a larger pain to manage if you are administering a lot of
> machines.  You also then have the extra task of making sure kernel and
> modules are always in sync ABI-wise (a static kernel is always 
> self-consistent).

I think using KLD more in our installer image makes a lot of sense.
It would allow people an option to not load USB modules if there is
a problem on their system that prevents proper installation with the
modules present.  I'd probably swing more on doing it in the loader
menu somehow than using loader.conf.

Sound drivers can probably be handed through devd as loading those
dymanically works much better than the USB stack. 


More information about the freebsd-arch mailing list