Re: [PATCH 11/14] nubus: Repopulate /proc/bus/nubus/s/

[Finn Thain <fthain@telegraphics.com.au>]

On Mon, 13 Nov 2017, Geert Uytterhoeven wrote:

> On Sat, Nov 11, 2017 at 7:12 AM, Finn Thain <fthain@telegraphics.com.au> 
> wrote:
> 
> > ---
> >  drivers/nubus/nubus.c | 117 +++++++++++++++++++++++++++-------
> >  drivers/nubus/proc.c  | 170 +++++++++++++++++++++++++++++++++++++++++++++++---
> >  include/linux/nubus.h |  35 ++++++++++-
> >  3 files changed, 288 insertions(+), 34 deletions(-)
> 
> Wow, that's much more code added than was removed by "[PATCH 10/14] 
> nubus: Depopulate /proc/bus/nubus/s/":
> 
>  drivers/nubus/proc.c  | 100 --------------------------------------------------
>  include/linux/nubus.h |   1 -
>  2 files changed, 101 deletions(-)
> 

You're right. The new code includes two structs file_operations and there 
is probably some redundancy in this arrangement. I'll see if it can be 
done with one set of file operations methods.

> How much memory is saved by not using the stored representation of slot 
> resource data?
> 

That question might be expressed as "how much RAM would be wasted by 
duplicating the contents of the slot ROM resources in RAM?".

Either way, the answer is hard to estimate because we don't know which 
resources will be accessed via procfs. (Resource IDs that are not known to 
nubus.c are omitted already though they may end up being needed.)

The few resources needed by sysfs are already stored in RAM at a cost of a 
tens of bytes per board. The resources required by drivers are read from 
ROM as needed and I think that's the simplest and cheapest approach for 
procfs too.

> BTW, should 10 and 11 be combined, to avoid a regression during 
> bisection?
> 

Right. There isn't any reason to separate them now. I'll squash them 
together.

Thanks for reviewing.

-- 

> Gr{oetje,eeting}s,
> 
>                         Geert
>