On Aug 29, 2013, at 8:54 AM, John Baldwin wrote:

> On Thursday, August 29, 2013 6:56:53 am Adrian Chadd wrote:
>> Hm! Are they dynamically loaded if you insert the cards?
>> 
>> (Ie, has devd been taught about them as appropriate?)
> 
> These are drivers for the bridges, not for cards you plug into the bridges.  
> If you autoloaded them at all you would load them during boot when you saw an 
> appropriate PCI device.  Currently we don't autoload any PCI drivers, so I 
> don't think that should be a blocker for taking these out of GENERIC.
> 
> Warner is probably the best person to ask.

We don't autoload them. The bridge code is tiny and can easily be removed if 
you want to create a custom kernel.  There's still plenty of laptops that would 
be crippled if these were removed. Other drivers that are even more obsolete 
that are still in GENERIC:
        esp
        sym
        trm
        adv
        adw
        aic
        bt
        asr
        ciss
        iir
        ida
        de
        cas
        dc
        gem
        hme
        nfe
        nve
        pcn (although many VM env like this)
        rl
        fs
        sis
        tl
        tx
        vr
        wb
        xl
        cs
        ed
        ex
        ep
        fe
        sn
        xe
        an
        wi
        urio
        uipaq
        aue
        cue
        kue
        rue

So asking why cbb and cardbus are still there seems a little silly to me.

The basic problem is that our PCI and USB infrastructure doesn't include the 
basic information necessarily to properly look at a directory of .ko files and 
know what to autoload when it finds an unmatched device. PC Card could easily 
do this, but doesn't (I have some doodles from a few years ago that would put 
this stuff into an elf section that could (a) be unloaded after probe 
(optionally) and (b) be read by automatic tools to load just what's needed). 
USB is a lot closer than PCI, which is why Hans' scripts work well enough to 
create uber-ugly devd config files.

Rather than shooting randomly, perhaps some investigation about this topic 
would be in order. We've talked it to death, but nobody has had the time to 
STFU and implement something reasonable.

Warner
_______________________________________________
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Reply via email to