Messages in this thread | | | Date | Fri, 25 Jan 2008 08:56:09 +0100 (CET) | From | Jan Engelhardt <> | Subject | Re: [PATCH] Linux Kernel Markers Support for Proprierary Modules |
| |
On Jan 24 2008 07:47, Mathieu Desnoyers wrote: >On Tue, 2008-01-22 at 22:10 -0500, Mathieu Desnoyers wrote: >On my part, its mostly a matter of not crashing the kernel when someone >tries to force modprobe of a proprietary module (where the checksums >doesn't match) on a kernel that supports the markers. Not doing so >causes the markers to try to find the marker-specific information in >struct module which doesn't exist and OOPSes.
>* Frank Ch. Eigler (fche@redhat.com) wrote: >[...] >Another way of looking at this though is that by allowing/encouraging >proprietary module writers to include markers, we and their users get >new diagnostic capabilities. It constitutes a little bit of opening >up, which IMO we should reward rather than punish.
Tackling this from a different angle:
I do not think there is a real reason to forceload a module, even those with proprietary origin (vmware) or that are of partially-closed nature (nvidia). vmware source is fully available, so can be compiled with proper modinfo/vermagic/markers; nvidia uses a build system trick to include an .o blob, but eventually its .ko also ends up with a correct modinfo/vermagic.
Forceload is for people which like to trade an unstable system for not having to install gcc and kernel-source.
>Remember - when a user tries a Linux box with a proprietary module, and the >experience sucks because the module sucks, they will walk away thinking >"Linux sucks", not "That module sucks".
So what is needed is an Oops with an explaining message if (kernel_tainted) "blame that proprietary module first", and make sure the user sees that oops even if in X.
| |