[Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages
david.s.gordon at intel.com
Tue Dec 8 03:19:28 PST 2015
On 07/12/15 19:13, Johannes Weiner wrote:
> On Mon, Dec 07, 2015 at 06:10:00PM +0000, Dave Gordon wrote:
>> Exporting random uncontrolled variables from the kernel to loaded modules is
>> not really considered best practice. It would be preferable to provide an
>> accessor function - which is just what the declaration says we have; the
>> implementation as a static inline (and/or macro) is what causes the problem
> No, what causes the problem is thinking we can't trust in-kernel code.
We 'trust' kernel code not to be malicious, but not to be designed or
implemented without mistakes. Keeping the impact of the mistakes as
small and local as possible increases overall system reliability and
makes debugging easier, which leads to the general principle of only
exporting the minimum necessary interfaces. If no other module should
write this data, then let's not export it as a read-write variable.
> If somebody screws up, we can fix it easily enough. Sure, we shouldn't
> be laying traps and create easy-to-misuse interfaces, but that's not
> what's happening here. There is no reason to add function overhead to
> what should be a single 'mov' instruction.
It could still be a macro or local inline within the mm code, but
provide a read-only function-call interface for external use. That gives
you maximum efficiency within the owning module, and makes it clear just
what sort of access is allowed outside that code.
More information about the Intel-gfx