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 ([EMAIL PROTECTED]) 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
