On Tue, 2015-12-22 at 12:34 +0100, Borislav Petkov wrote: > 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? The above example referred the case with distros, not with the upstream. That is, one writes a new loadable module and makes it available in the upstream. Then s/he makes it work on a distro used by the customers, but may or may not be able to change the distro kernel/drivers used by the customers. > 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. I agree that we can add new interfaces with the type check. This 'type' may need some clarification since it is an assigned type, which is different from I/O resource type. That is, "System RAM" is an I/O resource type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an assigned type to a particular range of System RAM. A range may be associated with multiple names, so as multiple assigned types. For lack of a better idea, I may call it 'assign_type'. I am open for a better name. > > 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. OK, I will try to convert the existing callers with the new interfaces. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
