On Tue, 2008-01-29 at 16:22 -0500, Pavel Roskin wrote:Yup. There was (what I thought was) a bug in the existing logic (an explicit match on "ndiswrapper", and a setting of the global kernel taint flags) and I corrected it to do what I thought it was actually intending to do, but hadn't been. Was I mistaken? What's the point of setting the global taint if we don't know why we set that? Yes it is. But I thought the existing code was intending to taint the kernel (that's what it does), so it would really help to identify why it tainted the kernel, by calling add_taint_module instead of add_taint. I didn't put the existing match in there...don't shoot the messenger :) Another fix would be for ndiswrapper to explicitly set the taint when it loads a tainted driver? Or do we just want to go back to globally "tainting" the kernel without assigning the blame to any module? Jon. --
| Justin C. Sherrill | Re: dragonflybsd.org website link? |
| David Woodhouse | Re: -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Eric Sandeen | Re: [RFC] Heads up on sys_fallocate() |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Patrick McHardy | [NET_SCHED 01/15]: sch_atm: fix format string warning |
