Hi Finn,
On Sat, Mar 25, 2023 at 12:33 AM Finn Thain <fthain@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx
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
