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

Finn Thain
2017-11-14T00:21:32Z

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
>