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. 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. 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.
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'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.
Regarding terminology, the files in /proc/bus/nubus/*/ are termed
"records" or "entries" while the subdirectories may represent boards, slot
resources or tables of entries. So a parameter like "proc_entries" (in
effect nubus.proc_entries) might be more apt than "procfs_rsrcs".
Linux "devices" correspond to the "functional resources" offered by a
card. (Other resources have other purposes.)
I don't know where the "local/private" designation originates from. It's
not to be found in Apple's book, "Designing Cards and Drivers for the
Macintosh". AFAIK, there's no distinction between "public" and "private"
like you might expect to find between the slot resources needed by Apple's
Slot Manager and those needed by 3rd party drivers. E.g. the
NUBUS_RESID_MAC_ADDRESS and NUBUS_RESID_GAMMADIR slot resources were
Apple-defined, even though nubus.c describes them as "local/private".
The split looks pretty artificial to me. I don't remember any details,
as I don't think I was looking at that part of the code at the time.
Brad Boyer
flar@xxxxxxxxxxxxx
