On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote:
> 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.
Huh?
Still sounds bogus to me. Distro kernels get stuff backported to them
all the time to accomodate new features, hw support.
Your new interfaces will be used only in new code so if distros want
it, they can either backport the new kernel interfaces or use an older
version with the strings.
> 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.
Or assigned_type or named_type or so...
I think we should avoid calling it "type" completely in order to avoid
confusion with the IORESOURCE_* types and call it "desc" or so to mean
description, sort, etc, because the name is also a description of the
resource to a certain degree...
> OK, I will try to convert the existing callers with the new interfaces.
Either that or add the new interfaces, use them in your use case, add
big fat comments explaining that people should use those from now on
when searching by name and add a check to checkpatch to catch future
mis-uses...
Thanks!
--
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>