Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC?

[Kimmo Paasiala]

In reference to this FreeBSD forums post:

http://forums.freebsd.org/showpost.php?p=231135&postcount=4

Would it be a good time to remove those from GENERIC since the
hardware they are for is becoming so seriously outdated?

There's always an option to load those drivers as modules if needed.

-Kimmo

[Adrian Chadd]

Hm! Are they dynamically loaded if you insert the cards?

(Ie, has devd been taught about them as appropriate?)


-adrian

Post by Kimmo Paasiala
http://forums.freebsd.org/showpost.php?p=231135&postcount=4
Would it be a good time to remove those from GENERIC since the
hardware they are for is becoming so seriously outdated?
There's always an option to load those drivers as modules if needed.
-Kimmo
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-current

[John Baldwin]

Post by Adrian Chadd
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.

[Warner Losh]

Post by John Baldwin

Post by Adrian Chadd
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

[Adrian Chadd]

. after tinkering in the USB world, i wonder what's wrong with this:

* created a basic markup / description language to encapsulate what PCI/USB
probing requires;
* generated both config files _and_ .c / .h files for drivers to include;
* have the kernel build process do .device_description -> .c/.h (for
compiling) ; devd.conf (for runtime loading); an elf section if you'd like;
and loader-mumble.conf (for loader autoloading.)



-adrian

[Warner Losh]

* created a basic markup / description language to encapsulate what PCI/USB probing requires;
* generated both config files _and_ .c / .h files for drivers to include;
* have the kernel build process do .device_description -> .c/.h (for compiling) ; devd.conf (for runtime loading); an elf section if you'd like; and loader-mumble.conf (for loader autoloading.)

It is needlessly complex? You seriously don't need 1/10th that complexity.

We've talked about solutions in the past. I even have something that will automatically do the heavy lifting for compliant drivers (or did before it decayed). What's needed is for someone to step in and drive it to completion.

Like I said, this has been talked to death at least half a dozen times.

Warner

[Warner Losh]

Post by Kimmo Paasiala
http://forums.freebsd.org/showpost.php?p=231135&postcount=4
Would it be a good time to remove those from GENERIC since the
hardware they are for is becoming so seriously outdated?
There's always an option to load those drivers as modules if needed.

No. It is not a good time to remove them. They aren't as out-dated as you might think, and there's literally dozens of other devices in GENERIC that have even less use today...

Warner

[Thomas Mueller]

Post by Kimmo Paasiala
http://forums.freebsd.org/showpost.php?p=231135&postcount=4
Would it be a good time to remove those from GENERIC since the
hardware they are for is becoming so seriously outdated?
There's always an option to load those drivers as modules if needed.
-Kimmo

These looked useless to me on a desktop computer, but proved necessary to retain just to be able to compile NDIS support into the kernel.

This is for a USB wireless adapter by Hiro that uses Realtek RTL8191S chip.

Other responses on this topic reveal that these cardbus drivers are needed for many other drivers too.


Tom