Re: [PATCH V6 02/15] cpufreq: Add cpufreq_table_len()

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Jan 13, 2025 at 01:00:40PM +0530, Viresh Kumar wrote:
> On 09-01-25, 08:35, Greg KH wrote:
> > Then why not make the C code use this function as well, to keep all
> > cpufreq drivers from having to manually walk the list and that way both
> > C and Rust drivers all do the same thing?  That makes more sense to me,
> > there's no reason you can't change C code today first to make things
> > more unified, in fact, that's usually a better idea overall anyway.
> 
> I investigated a bit on this..
> 
> - The cpufreq core normally gets (from cpufreq governor's for example)
>   a frequency value to be matched against in the freq-table, and the
>   loop which run over the freq-table is already optimized enough (it
>   checks for CPUFREQ_TABLE_END) for this. Using length in this loop
>   won't improve it anymore.
> 
> - The cpufreq core then calls cpufreq driver's callbacks and passes an
>   index to the freq-table, which the drivers don't need to verify
>   against table length, since the index came from the core itself.
> 
> - The same happens on the Rust side, where the cpufreq core calls the
>   target_index() callback of the driver. While writing the Rust code,
>   I thought maybe I should validate that the index is within limits
>   (before I do pointer manipulation in Rust code). And so required
>   this extra function (which C code never uses).
> 
> - Now I can either keep doing this verification in the Rust code (and
>   so keep the new API, only used by Rust code). Or I can just remove
>   the verification and trust that the index passed by the
>   cpufreq-drivers is correct (since they have received them from the
>   cpufreq C code).
> 
> What should I do ?

I would trust the C code, keeping the apis the same between the two
types of drivers.  If in the future you want to fix up the api, then fix
both drivers.  Don't try to have unique apis for only Rust drivers if
you can help it at all, that is just going to drive us all crazy over
time.

And really, you might want to fix up the api, that too sounds crazy :)

thanks,

greg k-h