From Fedora Project Wiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Tabular summary: Comparing kmods and kmdls

Is something is unclear please check the detailed comparison .

The rating is + for kmdl, - for kmod, 0 neutral. More important parts and larger differences get more symbols.

Feel free to add your own rating column.

kmods kmdls at's rating
features
kernel/kabi's id merged with the module's evr embedded in name
specfiles/src.rpm two, split for userland vs kernelland one
helper applications kmodtool none
kernel agnostic no, wants to become yes
kernel flavour agnostic no, wants to become yes
design/flexibility interface is implementation interface/implementation abstraction
bundled flavour builds yes no
comparison: rpm +++
rpm breaks on rpm level, no fix possible like conventional packages +++
rpm -U does not work (see above) already rated above
rpm -i does not work (see above) already rated above
$1 in scriplets does not work works ++
comparison: yum and other depsolvers +++
w/o plugin and new kernels installs the kmod for the latest kernel no coinstallation for new kernels --
w/o plugin and module upgrades file conflicts on test transaction proper upgrading +++
w/ full plugin support (best case) only one kernel supportable,
no updates for other kernels,
can even deactivate/remove kernel modules from other kernels
all kernels get full support +++++
other depsolvers (smart/apt) require special handling as yum trivial pluginization, in works +
comparison: short-term maintenance/development +++++
further yum development needed for fixing the above none needed +++++
debuginfo support no changes part of macros 0
rpmbuild no changes 0
mock, mach, etc. no changes 0
buildsystem
repomanagement
needs special handling (what kernels to support, what flavours exist, cleaning up old kernel modules when cleaning up kernels from repo) 0
comparison: long-term maintenance ++
infrastructure needs two bugzilla/owners/scm folders
How does user know whether a bug is in userland or kmod?
like conventional packages (just one entry) ++
rebuilds for new kernels
(often)
every new kernel needs specfile/src.rpm changes specfile/src.rpm/userland invariant ++
rebuilds for new flavours
(seldom)
full rebuild of every other flavour specfile/src.rpm/userland/other flavours invariant +
comparison: standardization +
existing standard of Fedora yes no --
Other distributions - runs on RHEL4/3, FC1-6, RHL7.3-9 ++
Cross distribution standard - aims to become one
already tested on Mandriva,
would work on SuSE
++
support different implementations
still same specfile/src.rpm
- yes +
comparison: flexibility +++
debuginfo bundling and flavour builds all kmods share one debuginfo
=> need to always bundle (re)builds of all flavours
each kmdl has its own
(re)builds for kernel/flavour separate
+
kabi support none already supported by interface
no specfile/src.rpm/userland changes
+++
custom kernel support only if 100% like a Fedora kernel
(including name conflict)
forces custom kernels to violate no-replacement-of-core-packages
full, in practice since several years ++
comparison: current investment and experience ---
procedures to become a Fedora standard all finished trying to convince Fedora pricipals ---
existing kmods/kmdls in Fedora yes, only one, but half a dozen in queue none --
existing kmods/kmdls in 3rd parties half a dozen at livna several dozens at ATrpms +