On Tue, 2013-04-09 at 12:51 -0700, Andrew Morton wrote:
> On Tue, 09 Apr 2013 13:02:30 -0600 Toshi Kani <toshi.k...@hp.com> wrote:
>
> > > > + /* look for the next resource if it does not fit into */
> > > > + if (res->start > start || res->end < end) {
> > > > + p = &res->sibling;
> > > > + continue;
> > > > + }
> > >
> > > What if the resource overlaps. In other words, the res->start > start
> > > but res->end > end ?
> > >
> > > Also do you handle the case where the range <start,end> spans
> > > across multiple adjacent resources?
> >
> > Good questions! The two cases above are handled as error cases
> > (-EINVAL) by design. A requested region must either match exactly or
> > fit into a single resource entry. There are basically two design
> > choices in release -- restrictive or non-restrictive. Restrictive only
> > releases under certain conditions, and non-restrictive releases under
> > any conditions. Since the existing release interfaces,
> > __release_region() and __release_resource(), are restrictive, I intend
> > to follow the same policy and made this new interface restrictive as
> > well. This new interface handles the common scenarios of memory
> > hot-plug operations well. I think your example cases are non-typical
> > scenarios for memory hot-plug, and I am not sure if they happen under
> > normal cases at this point. Hence, they are handled as error cases for
> > now. We can always enhance this interface when we find them necessary
> > to support as this interface is dedicated for memory hot-plug. In other
> > words, we should make such enhancement after we understand their
> > scenarios well. Does it make sense?
>
> Can you please update the comment to describe the above? Because if
> one reviewer was wondering then later readers will also wonder.
Yes, I will update the comment and send an updated patch again.
Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
