[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v8 03/24] x86: refactor psr: implement main data structures.



>>> On 01.03.17 at 09:28, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> On 17-03-01 01:17:22, Jan Beulich wrote:
>> >>> On 01.03.17 at 06:10, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
>> > On 17-02-28 11:58:59, Roger Pau Monn wrote:
>> >> On Wed, Feb 15, 2017 at 04:49:18PM +0800, Yi Sun wrote:
>> >> > +    struct feat_ops ops;
>> >> 
>> >> I would place the function hooks in this struct directly, instead of 
> nesting
>> >> them inside of another struct. The hooks AFAICT are shared between all the
>> >> different PSR features.
>> >> 
>> > Jan suggested this before in v4 patch. We have discussed this and Jan 
>> > accepts
>> > current implementation. The reason is below:
>> 
>> I'm pretty sure I didn't (in this specific form). Instead you want this
>> to be a pointer (to a const struct instance), i.e. ...
>> 
> Sorry for confusion. I think you suggested same thing (maybe I 
> misunderstood?).
> 
> Quoted from v4:
> "What is the reason to have a separate structure for this, when you
> don't store a pointer in struct feat_node? If this was inlined there,
> the odd forward declaration of struct feat_node wouldn't be needed
> either. (The same question may apply to struct feat_hw_info.)"
> 
> So I explained as below and asked if you can accept such implementation. And
> got your positive ack. Of course, I should declare l3_cat_ops to const.

In which case an earlier question to answer is: Why can it not be a
pointer that gets stored?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.