Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <5b7c473247d66776343d82a55b9815195b1b11fb.1679551394.git.fthain@linux-m68k.org>
 <CAMuHMdUJ6kbpYGTjyY5dX+-YRv3pL0ydG3HQ-H1khyeqLOa05A@mail.gmail.com>
 <072fd894-ec50-ae5f-2be5-ebbeb0e7b39b@linux-m68k.org> <20230324085927.GA6354@allandria.com>
 <0cd7f288-ba43-7764-01a7-2e1e5c7a1640@linux-m68k.org>
In-Reply-To: <0cd7f288-ba43-7764-01a7-2e1e5c7a1640@linux-m68k.org>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Sat, 25 Mar 2023 13:44:43 +0100
Message-ID: <CAMuHMdXi1mF=j_Qzzg971AqHF-JdgfaDd+v0HymXXusFt-WBUQ@mail.gmail.com>
Subject: Re: [PATCH v2] nubus: Don't list card resources by default
To:     Finn Thain <fthain@linux-m68k.org>
Cc:     Brad Boyer <flar@allandria.com>, linux-m68k@lists.linux-m68k.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

Hi Finn,

On Sat, Mar 25, 2023 at 12:33 AM Finn Thain <fthain@linux-m68k.org> wrote:
> On Fri, 24 Mar 2023, Brad Boyer wrote:
> > On Fri, Mar 24, 2023 at 10:13:51AM +1100, Finn Thain wrote:
> > > On Thu, 23 Mar 2023, Geert Uytterhoeven wrote:
> > > > On Thu, Mar 23, 2023 at 7:02???AM Finn Thain <fthain@linux-m68k.org> wrote:
> > > > > --- a/drivers/nubus/nubus.c
> > > > > +++ b/drivers/nubus/nubus.c
> > > > > @@ -34,6 +34,9 @@
> > > > >
> > > > >  LIST_HEAD(nubus_func_rsrcs);
> > > > >
> > > > > +bool procfs_rsrcs;
> > > > > +module_param(procfs_rsrcs, bool, 0444);
> > > >
> > > > With the expanded functionality, is "rsrcs" still a good name?
> > > > Perhaps this should be an integer, so you can define different
> > > > levels? E.g.
> > > >   - 0 = just devices
> > > >   - 1 = above + boards + public resources
> > > >   - 2 = above + private resources
> > >
> > > That really depends on how the proc entries get used. I think it's
> > > probably going to be developers who would use them so I consider all
> > > of this to be outside of the UAPI and subject to change. But it would
> > > be nice to hear from other developers on that point.
> >
> > I don't know of anything that currently uses them, but there's a number
> > of potential uses depending on how far we want to take things. A real
> > video driver for X.org for some of the more advanced cards could take
> > advantage of some of the secondary information made available. I've got
> > a number of NuBus video cards with some acceleration capabilities that
> > were pretty advanced for the time.
>
> Good point. I had not considered Xorg drivers. But I'm not sure why
> userspace drivers would access /proc when they already need /dev/mem or
> some more modern graphics API to be implemented by an in-kernel driver.
>
> > There's even a driver in the ROM on video cards that could be used, but
> > that also requires more emulation of the MacOS environment. KVM could
> > potentially need more information if we got it running on m68k, although
> > I doubt any real Mac has enough RAM to make that useful.
>
> You only need a few MB to run MacOS (or an early Linux distro). So I
> rather think that KVM could be workable with 64 or 128 MB of RAM.
>
> The /proc/bus/nubus/boards file is not affected by this patch, so userland
> tools could still identify the available boards if need be.

Perhaps it would be worthwhile to move the resources out of /proc,
but into a separate virtual file system?
That way people who need access to the additional info can load the
separate virtual file system kernel module, and mount the file system?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds