On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote:
> This scheme may have a problem, though. For instance, when someone writes
> a loadable module that searches for "foo", but the "foo" entry may be
> initialized in a distro kernel/driver that cannot be modified. Since this
> search is only necessary to obtain a range initialized by other module,
> this scenario is likely to happen. We no longer have ability to search for
> a new entry unless we modify the code that initializes the entry first.
Since when do we pay attention to out-of-tree modules which cannot be
changed?
Regardless, we don't necessarily need to change the callers - we could
add new ones of the form walk_iomem_resource_by_type() or whatever its
name is going to be which uses the ->type attribute of the resource and
phase out the old ones slowly. New code will call the better interfaces,
we should probably even add a checkpatch rule to check for that.
> Even if we avoid strcmp() with @name in the kernel, user applications will
> continue to use @name since that is the only type available in /proc/iomem.
> For instance, kexec has its own search function with a string name.
See above.
> When a new commonly-used search name comes up, we can define it as a new
> extended I/O resource type similar to IORESOURCE_SYSTEM_RAM. For the
> current remaining cases, i.e. crash, kexec, and einj, they have no impact
> to performance. Leaving these special cases aside will keep the ability to
> search for any entry without changing the kernel, and save some memory
> space from adding the new 'type'.
Again, we can leave the old interfaces at peace but going forward, we
should make the searching for resources saner and stop using silly
strings.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>