Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani <toshi.kani@hpe.com>]

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