Messages in this thread | | | Date | Mon, 14 Mar 2016 19:08:36 +0100 | From | Borislav Petkov <> | Subject | Re: [RFC PATCH] Unexport do_machine_check() and machine_check_poll() |
| |
On Mon, Mar 14, 2016 at 09:55:17AM -0700, Luck, Tony wrote: > It doesn't seem like a very natural fit ... the three routines > take very different arguments which you bundle into a "void *".
Yeah, that was the quick'n'dirty approach.
> I'm also not sure what we gain. Now we have one, complicated, > exported function that still lets modules do all the things > they could do with the three separate functions. Is there some > benefit to having fewer exports?
So the small benefit is that our ABI has a single function instead of two.
> What am I missing?
Yeah, you're right the patch is probably not the right thing to do.
But the sentiment is: I want to unexport do_machine_check() and machine_check_poll() and not let external modules call into them directly. Why, you ask? Because they have no business doing that. Those two are MCA, more-or-less, internal functionality and it probably is ok if mce-inject or kvm/vmx use them but the export is IMO too wide. Think out-of-tree modules and whatnot here.
So I guess exporting even mce_call() is wrong - I'd like to not export anything to users and allow only the existing two mce-inject and kvm/vmx call them.
But the original reason why I started looking at those is that during a backport to SLE11, I had a kABI issue due to machine_check_poll() and I started questioning why is that function even exported? And it shouldn't be - internal kernel users should be able to get that functionality in a different way, without the wide export. I probably should think a bit more about how.
I hope I'm making a bit more sense now...
-- Regards/Gruss, Boris.
ECO tip #101: Trim your mails when you reply.
| |