Hi Brad,
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.
I haven't looked at a Radius Rocket (a Mac on a card) to see if it has
anything useful in these, but I wouldn't be surprised if there are
useful things there. I've never tried to boot Linux on a system with one
installed or booting Linux on the card itself. I have booted a second
instance of the MacOS on one, and I seem to recall it shows up as a
Q900. I have a couple x86 system cards that were intended to run DOS as
well. There was an Apple II card for the LC slot, but I don't own one.
LC slot cards show up in software as NuBus, as I recall.
I think those cards are in the same category as video cards in the sense
that userspace drivers would need /dev/mem.
It wouldn't be in userspace, but we could end up needing to pull
firmware out of them for a number of different cards. I've got a couple
SCSI cards that would need to have firmware loaded at runtime, and the
ROM would have the default version even if we also allow a firmware file
to override that. Based on the existing qlogicpti.c code, the ISP 1000
chip (found on ATTO SiliconExpress IV cards) needs firmware. The older
SiliconExpress cards all appear to use various ESP chips, so they likely
don't need anything special. I suspect the various MCP based cards have
useful things on the ROM for a driver to use. They each have a 68000
chip on them running A/ROSE, which is presumably loaded from firmware as
well. I have both ethernet and serial cards based on this platform. It
appears that a driver for the specific card has to be loaded into A/ROSE
on the card after it boots.
I had not considered that /proc could be used that way. Unfortunately, the
length of procfs entries is limited to PAGESIZE. Larger entries are listed
but have length 0. So I think this isn't going to fly.
Probably /dev/mem or a MacOS utility, or a ROM dump created by a MacOS
utility, would be needed to extract firmware from the MacOS ROM, such as
the firmware used by the IOP co-processors (which are standard equipment
on some models). The same solutions (though not ideal) could also work for
slot resources.
I've got a bunch of cards that I've never even looked at the resources
built into the ROM chips, so I'm guessing on what might or might not be
useful. At one point I was buying every card I could find that looked
interesting, and many of them I've never tested. I have crates full of
stuff, plus a bunch stacked up that came in original boxes.
Checking them is disabled now, but some Macs have fake NuBus resources
for some of the onboard devices that show up as if they were in a
virtual NuBus slot 0. Scanning that apparently caused problems on some
models (presumably a bus error, since it would be accessing invalid
addresses). Really old kernels had code to scan that protected by a
compile time option.
I can't figure out why procfs access to the slot resources from pseudo
slot 0 would be desirable (?)
