Some Nubus cards have many ROM resources. A single Radius video card
produced well over a thousand entries under /proc/bus/nubus/. Populating
/proc/bus/nubus on a slow machine with several such cards installed takes
long enough that the user may think that the system is wedged. All those
procfs entries also consume significant RAM though they are not normally
needed (except by developers). Omit these resources from /proc/bus/nubus/
by default and add a kernel parameter to enable them when needed.
On the test machine, this saved 300 kB and 10 seconds.
Tested-by: Stan Johnson <[email protected]>
Signed-off-by: Finn Thain <[email protected]>
---
Checkpatch says "externs should be avoided in .c files" and if this one
appeared twice I would agree. But as it only appears once, I can't see
any advantage to putting it in a new .h file instead of the .c file...
---
drivers/nubus/nubus.c | 7 ++++++-
drivers/nubus/proc.c | 10 ++++++----
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index f70ba58dbc55..925aec257e1b 100644
--- 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);
+
/* Meaning of "bytelanes":
The card ROM may appear on any or all bytes of each long word in
@@ -574,7 +577,9 @@ nubus_get_functional_resource(struct nubus_board *board, int slot,
default:
/* Local/Private resources have their own
function */
- nubus_get_private_resource(fres, dir.procdir, &ent);
+ if (procfs_rsrcs)
+ nubus_get_private_resource(fres, dir.procdir,
+ &ent);
}
}
diff --git a/drivers/nubus/proc.c b/drivers/nubus/proc.c
index 2c320a84fd72..844e86636798 100644
--- a/drivers/nubus/proc.c
+++ b/drivers/nubus/proc.c
@@ -51,11 +51,13 @@ static struct proc_dir_entry *proc_bus_nubus_dir;
* /proc/bus/nubus/x/ stuff
*/
+extern bool procfs_rsrcs;
+
struct proc_dir_entry *nubus_proc_add_board(struct nubus_board *board)
{
char name[2];
- if (!proc_bus_nubus_dir)
+ if (!proc_bus_nubus_dir || !procfs_rsrcs)
return NULL;
snprintf(name, sizeof(name), "%x", board->slot);
return proc_mkdir(name, proc_bus_nubus_dir);
@@ -72,7 +74,7 @@ struct proc_dir_entry *nubus_proc_add_rsrc_dir(struct proc_dir_entry *procdir,
char name[9];
int lanes = board->lanes;
- if (!procdir)
+ if (!procdir || !procfs_rsrcs)
return NULL;
snprintf(name, sizeof(name), "%x", ent->type);
remove_proc_subtree(name, procdir);
@@ -157,7 +159,7 @@ void nubus_proc_add_rsrc_mem(struct proc_dir_entry *procdir,
char name[9];
struct nubus_proc_pde_data *pded;
- if (!procdir)
+ if (!procdir || !procfs_rsrcs)
return;
snprintf(name, sizeof(name), "%x", ent->type);
@@ -176,7 +178,7 @@ void nubus_proc_add_rsrc(struct proc_dir_entry *procdir,
char name[9];
unsigned char *data = (unsigned char *)ent->data;
- if (!procdir)
+ if (!procdir || !procfs_rsrcs)
return;
snprintf(name, sizeof(name), "%x", ent->type);
--
2.37.5
Hi Finn,
On Thu, Mar 23, 2023 at 7:02 AM Finn Thain <[email protected]> wrote:
> Some Nubus cards have many ROM resources. A single Radius video card
> produced well over a thousand entries under /proc/bus/nubus/. Populating
> /proc/bus/nubus on a slow machine with several such cards installed takes
> long enough that the user may think that the system is wedged. All those
> procfs entries also consume significant RAM though they are not normally
> needed (except by developers). Omit these resources from /proc/bus/nubus/
> by default and add a kernel parameter to enable them when needed.
> On the test machine, this saved 300 kB and 10 seconds.
>
> Tested-by: Stan Johnson <[email protected]>
> Signed-off-by: Finn Thain <[email protected]>
Thanks for your patch!
> Checkpatch says "externs should be avoided in .c files" and if this one
> appeared twice I would agree. But as it only appears once, I can't see
> any advantage to putting it in a new .h file instead of the .c file...
The advantage is that it allows the compiler to check that the
signatures of the declaration and the definition do match, now and in
the future.
> --- 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
(disclaimer: I know nothing about NuBus and the current /proc/nubus
layout)
Should this be documented?
I know there is currently nothing about NuBus under Documentation/.
> +
> /* Meaning of "bytelanes":
>
> The card ROM may appear on any or all bytes of each long word in
> @@ -574,7 +577,9 @@ nubus_get_functional_resource(struct nubus_board *board, int slot,
> default:
> /* Local/Private resources have their own
> function */
> - nubus_get_private_resource(fres, dir.procdir, &ent);
> + if (procfs_rsrcs)
> + nubus_get_private_resource(fres, dir.procdir,
> + &ent);
> }
> }
>
> diff --git a/drivers/nubus/proc.c b/drivers/nubus/proc.c
> index 2c320a84fd72..844e86636798 100644
> --- a/drivers/nubus/proc.c
> +++ b/drivers/nubus/proc.c
> @@ -51,11 +51,13 @@ static struct proc_dir_entry *proc_bus_nubus_dir;
> * /proc/bus/nubus/x/ stuff
> */
>
> +extern bool procfs_rsrcs;
> +
> struct proc_dir_entry *nubus_proc_add_board(struct nubus_board *board)
> {
> char name[2];
>
> - if (!proc_bus_nubus_dir)
> + if (!proc_bus_nubus_dir || !procfs_rsrcs)
> return NULL;
> snprintf(name, sizeof(name), "%x", board->slot);
> return proc_mkdir(name, proc_bus_nubus_dir);
> @@ -72,7 +74,7 @@ struct proc_dir_entry *nubus_proc_add_rsrc_dir(struct proc_dir_entry *procdir,
> char name[9];
> int lanes = board->lanes;
>
> - if (!procdir)
> + if (!procdir || !procfs_rsrcs)
> return NULL;
> snprintf(name, sizeof(name), "%x", ent->type);
> remove_proc_subtree(name, procdir);
> @@ -157,7 +159,7 @@ void nubus_proc_add_rsrc_mem(struct proc_dir_entry *procdir,
> char name[9];
> struct nubus_proc_pde_data *pded;
>
> - if (!procdir)
> + if (!procdir || !procfs_rsrcs)
> return;
>
> snprintf(name, sizeof(name), "%x", ent->type);
> @@ -176,7 +178,7 @@ void nubus_proc_add_rsrc(struct proc_dir_entry *procdir,
> char name[9];
> unsigned char *data = (unsigned char *)ent->data;
>
> - if (!procdir)
> + if (!procdir || !procfs_rsrcs)
> return;
>
> snprintf(name, sizeof(name), "%x", ent->type);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi Andreas,
On Thu, Mar 23, 2023 at 9:39 AM Andreas Schwab <[email protected]> wrote:
> On Mär 23 2023, Finn Thain wrote:
>
> > Checkpatch says "externs should be avoided in .c files" and if this one
> > appeared twice I would agree. But as it only appears once, I can't see
> > any advantage to putting it in a new .h file instead of the .c file...
>
> Anything wrong with declaring it in <linux/nubus.h>?
It's not meant for NuBus device drivers (at least in its current form).
So a drivers/nubus/nubus.h would be the most logical place.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Mär 23 2023, Finn Thain wrote:
> Checkpatch says "externs should be avoided in .c files" and if this one
> appeared twice I would agree. But as it only appears once, I can't see
> any advantage to putting it in a new .h file instead of the .c file...
Anything wrong with declaring it in <linux/nubus.h>?
--
Andreas Schwab, [email protected]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Thu, 23 Mar 2023, Geert Uytterhoeven wrote:
> On Thu, Mar 23, 2023 at 7:02 AM Finn Thain <[email protected]> wrote:
> > Some Nubus cards have many ROM resources. A single Radius video card
> > produced well over a thousand entries under /proc/bus/nubus/. Populating
> > /proc/bus/nubus on a slow machine with several such cards installed takes
> > long enough that the user may think that the system is wedged. All those
> > procfs entries also consume significant RAM though they are not normally
> > needed (except by developers). Omit these resources from /proc/bus/nubus/
> > by default and add a kernel parameter to enable them when needed.
> > On the test machine, this saved 300 kB and 10 seconds.
> >
> > Tested-by: Stan Johnson <[email protected]>
> > Signed-off-by: Finn Thain <[email protected]>
>
> Thanks for your patch!
>
Thanks for your review.
> > Checkpatch says "externs should be avoided in .c files" and if this one
> > appeared twice I would agree. But as it only appears once, I can't see
> > any advantage to putting it in a new .h file instead of the .c file...
>
> The advantage is that it allows the compiler to check that the
> signatures of the declaration and the definition do match, now and in
> the future.
>
Ah yes, I forgot that we use a header file to make sure that the header
file is correct ;-)
> > --- 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.
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".
Note that this patch doesn't affect the /proc/bus/nubus/boards file which
lists category, type, dr_sw, dr_hw for every functional resource
implemented by every board.
> (disclaimer: I know nothing about NuBus and the current /proc/nubus
> layout)
Here's an example from my LCIII. There's only one card (in slot e) and it
has minimal resources and entries. e/1 is the "vendor info" slot resource,
e/1/3 is the "revision" entry from that slot resource.
# grep -ar . /proc/bus/nubus
/proc/bus/nubus/e/1/1:
/proc/bus/nubus/e/1/2:Ethernet A-Series
/proc/bus/nubus/e/1/20:
/proc/bus/nubus/e/1/24/1:A-Series
/proc/bus/nubus/e/1/24/3:001
/proc/bus/nubus/e/1/24/4:SS DEV
/proc/bus/nubus/e/80/1:
/proc/bus/nubus/e/80/2:Network_Ethernet_A_Series
/proc/bus/nubus/e/80/a:
/proc/bus/nubus/e/80/80:[snipped binary MAC address]
/proc/bus/nubus/devices:e 0004 0001 010c 0100 fe000000
#
With this patch, only the /proc/bus/nubus/devices file appears by default.
nubus.c captures that information for bus matching purposes, but the
/proc/bus/nubus/e/* inodes are unused AFAIK. I think they were put there
so that userland programs could find uses for them. Problem is, it can be
expensive to do that, depending on the card ROM, and hence this patch.
>
> Should this be documented? I know there is currently nothing about NuBus
> under Documentation/.
>
Probably...
> > +
> > /* Meaning of "bytelanes":
> >
> > The card ROM may appear on any or all bytes of each long word in
> > @@ -574,7 +577,9 @@ nubus_get_functional_resource(struct nubus_board *board, int slot,
> > default:
> > /* Local/Private resources have their own
> > function */
> > - nubus_get_private_resource(fres, dir.procdir, &ent);
> > + if (procfs_rsrcs)
> > + nubus_get_private_resource(fres, dir.procdir,
> > + &ent);
> > }
> > }
> >
> > diff --git a/drivers/nubus/proc.c b/drivers/nubus/proc.c
> > index 2c320a84fd72..844e86636798 100644
> > --- a/drivers/nubus/proc.c
> > +++ b/drivers/nubus/proc.c
> > @@ -51,11 +51,13 @@ static struct proc_dir_entry *proc_bus_nubus_dir;
> > * /proc/bus/nubus/x/ stuff
> > */
> >
> > +extern bool procfs_rsrcs;
> > +
> > struct proc_dir_entry *nubus_proc_add_board(struct nubus_board *board)
> > {
> > char name[2];
> >
> > - if (!proc_bus_nubus_dir)
> > + if (!proc_bus_nubus_dir || !procfs_rsrcs)
> > return NULL;
> > snprintf(name, sizeof(name), "%x", board->slot);
> > return proc_mkdir(name, proc_bus_nubus_dir);
> > @@ -72,7 +74,7 @@ struct proc_dir_entry *nubus_proc_add_rsrc_dir(struct proc_dir_entry *procdir,
> > char name[9];
> > int lanes = board->lanes;
> >
> > - if (!procdir)
> > + if (!procdir || !procfs_rsrcs)
> > return NULL;
> > snprintf(name, sizeof(name), "%x", ent->type);
> > remove_proc_subtree(name, procdir);
> > @@ -157,7 +159,7 @@ void nubus_proc_add_rsrc_mem(struct proc_dir_entry *procdir,
> > char name[9];
> > struct nubus_proc_pde_data *pded;
> >
> > - if (!procdir)
> > + if (!procdir || !procfs_rsrcs)
> > return;
> >
> > snprintf(name, sizeof(name), "%x", ent->type);
> > @@ -176,7 +178,7 @@ void nubus_proc_add_rsrc(struct proc_dir_entry *procdir,
> > char name[9];
> > unsigned char *data = (unsigned char *)ent->data;
> >
> > - if (!procdir)
> > + if (!procdir || !procfs_rsrcs)
> > return;
> >
> > snprintf(name, sizeof(name), "%x", ent->type);
>
On Thu, 23 Mar 2023, Geert Uytterhoeven wrote:
> On Thu, Mar 23, 2023 at 9:39 AM Andreas Schwab <[email protected]> wrote:
> > On Mär 23 2023, Finn Thain wrote:
> >
> > > Checkpatch says "externs should be avoided in .c files" and if this one
> > > appeared twice I would agree. But as it only appears once, I can't see
> > > any advantage to putting it in a new .h file instead of the .c file...
> >
> > Anything wrong with declaring it in <linux/nubus.h>?
>
> It's not meant for NuBus device drivers (at least in its current form).
> So a drivers/nubus/nubus.h would be the most logical place.
>
I think Andreas is right inasmuchas the existing prototypes shared between
drivers/nubus/nubus.c and drivers/nubus/proc.c are found there, and this
extern is another one of those.
But I take Geert's point that much of include/linux/nubus.h could be moved
to drivers/nubus/something.h. But is there anything to be gained from
splitting it up that way?
Hi Finn,
On Fri, Mar 24, 2023 at 1:05 AM Finn Thain <[email protected]> wrote:
> On Thu, 23 Mar 2023, Geert Uytterhoeven wrote:
> > On Thu, Mar 23, 2023 at 9:39 AM Andreas Schwab <[email protected]> wrote:
> > > On Mär 23 2023, Finn Thain wrote:
> > > > Checkpatch says "externs should be avoided in .c files" and if this one
> > > > appeared twice I would agree. But as it only appears once, I can't see
> > > > any advantage to putting it in a new .h file instead of the .c file...
> > >
> > > Anything wrong with declaring it in <linux/nubus.h>?
> >
> > It's not meant for NuBus device drivers (at least in its current form).
> > So a drivers/nubus/nubus.h would be the most logical place.
>
> I think Andreas is right inasmuchas the existing prototypes shared between
> drivers/nubus/nubus.c and drivers/nubus/proc.c are found there, and this
> extern is another one of those.
>
> But I take Geert's point that much of include/linux/nubus.h could be moved
> to drivers/nubus/something.h. But is there anything to be gained from
> splitting it up that way?
Splitting it would prevent NuBus device drivers from messing with
internal NuBus variables they're not intended to access.
But I agree that's not a big concern...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
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 <[email protected]> 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
[email protected]
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 <[email protected]> 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 (?)
Hi Finn,
On Sat, Mar 25, 2023 at 12:33 AM Finn Thain <[email protected]> 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 <[email protected]> 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 -- [email protected]
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
On Sat, Mar 25, 2023 at 10:35:52AM +1100, Finn Thain wrote:
> On Fri, 24 Mar 2023, Brad Boyer wrote:
> > On Fri, Mar 24, 2023 at 10:13:51AM +1100, Finn Thain wrote:
> > > 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.
I suppose so. I haven't looked at any of that in years. Back in the
past a ton of that was being done outside the kernel. X.org used to
manually parse the PCI tree and do a bunch of stuff on its own.
> > 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.
That's probably enough, then. Device pass-through would be the main
place that would need more, but it would need full access to all
the slot memory anyway. That might even be a bad idea in general due
to the lack of an IOMMU. There are DMA capable cards which would then
have access to system memory. The kernel side of KVM doesn't look too
painful to implement, and m68k doesn't have some of the strange issues
of older x86 chips for running a VM.
> > 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.
Probably. I was just thinking that having some of the information
already parsed out might be useful. It's hard to say without having
anything written to use it.
> > 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.
To be honest, anything in the kernel should have an explicit API out
of the NuBus infrastructure rather than poking at these virtual files.
That could be done without pre-loading all this stuff into memory. A
similar API out of the core macintosh support code could do the same
for the system ROM.
I was looking into a more complete IOP driver, and wrote a few parts
of it. Doing it right will require reloading the embedded kernel into
each IOP as well as the individual channel drivers. Those are in the
ROM somewhere, as well as updated versions in system files. That's the
only practical way to pull an IOP out of bypass mode, as otherwise it
requires making a request that includes information that was passed
in when it was originally put into bypass mode. While we could probably
extract that out of IOP memory, it's not entirely clear (and definitely
undocumented) where it keeps that. We currently only use the individual
channel API calls (and only for ADB), but there's a whole separate IOP
kernel API that does a bunch of other useful stuff like managing bypass
mode and doing data transfer.
However, the system ROM doesn't use exactly the same structure as a
NuBus expansion ROM. That might complicate such work. It might be
easier to use the firmware infrastructure to load them from files
and extract the drivers from the latest system software that still
supported anything with an IOP. The updated IOP drivers are each
separate resources in the system file that could be extracted with
native developer utilities in MacOS. Then we presumably have the
latest. I've never found any hint that the IOP hardware was any
different between models that have them.
> > 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 (?)
I'm not sure. Someone clearly thought it was useful in the past. I don't
think I have any models with anything interesting there. I suspect the
main thing would be an equivalent to the ROM on a video card for the
built-in display adapter on those systems.
Brad Boyer
[email protected]
On Sat, Mar 25, 2023 at 01:44:43PM +0100, Geert Uytterhoeven wrote:
> 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?
I could be wrong, but I believe the more recent trend has been to
move things like this out of /proc anyway.
Brad Boyer
[email protected]
On Sat, 25 Mar 2023, Brad Boyer wrote:
> On Sat, Mar 25, 2023 at 10:35:52AM +1100, Finn Thain wrote:
>
> >
> > I think those cards are in the same category as video cards in the
> > sense that userspace drivers would need /dev/mem.
>
> Probably. I was just thinking that having some of the information
> already parsed out might be useful. It's hard to say without having
> anything written to use it.
>
If someone wanted to write something that uses the procfs information they
could still do so, but they would have to enable a kernel parameter first.
> ...
> However, the system ROM doesn't use exactly the same structure as a
> NuBus expansion ROM. That might complicate such work. It might be easier
> to use the firmware infrastructure to load them from files and extract
> the drivers from the latest system software that still supported
> anything with an IOP. The updated IOP drivers are each separate
> resources in the system file that could be extracted with native
> developer utilities in MacOS. Then we presumably have the latest. I've
> never found any hint that the IOP hardware was any different between
> models that have them.
>
My thinking was that a firmware cutter (whether it was for ROM resources
or slot resources) would remain separate from the kernel, as that seems to
be the usual pattern. The existing mechanisms for distributing to
/lib/firmware and loading from /lib/firmware could be leveraged.
> > I can't figure out why procfs access to the slot resources from pseudo
> > slot 0 would be desirable (?)
>
> I'm not sure. Someone clearly thought it was useful in the past.
That's not clear to me.
Someone clearly thought that the procfs files may be useful for some
unknown purpose in userspace. And someone clearly thought that the slot 0
resources may be useful for configuring drivers in kernelspace.
Neither of those panned out.
The only possible use I can think of for slot 0 resources in userspace
(e.g. a "TechTool" for Linux) would be better served by mmap'ing the ROM
using /dev/mem.
> I don't think I have any models with anything interesting there. I
> suspect the main thing would be an equivalent to the ROM on a video card
> for the built-in display adapter on those systems.
>
Only to the extent that such hardware cannot be probed or simply inferred
from bootinfo records already provided (like gestalt id). But the slot 0
vs. bootinfo question seems unrelated to the procfs question, right?
Hi Brad,
On Sun, Mar 26, 2023 at 1:03 AM Brad Boyer <[email protected]> wrote:
> On Sat, Mar 25, 2023 at 01:44:43PM +0100, Geert Uytterhoeven wrote:
> > 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?
>
> I could be wrong, but I believe the more recent trend has been to
> move things like this out of /proc anyway.
Correct. Use sysfs, debugfs, configfs, or your own custom file system
where appropriate.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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