Re: Sub-architectures in update-modules
On Tue, 1 Aug 2000, Philip Blundell wrote:
> Let's stick with just `acorn' for now and see what happens. I think
> Archimedes/A680/A5000 can certainly share one set of modules. RiscPC
> obviously needs different ones but confusion should be minimal - call them
> `acorn32' if you like.
<resurrection>
Okay; here's a suggestion for an example hardware name to subarch
mapping:
EBSA110 -> ?
Acorn-RiscPC -> acorn
FTV/PCI -> ?
EBSA285 -> ?
Rebel-Netwinder -> netwinder
Chalice-CATS -> ?
unknown-TBOX -> ?
co-EBSA285 -> ?
CL-PS7110 -> ?
Acorn-Archimedes -> acorn26
Acorn-A5000 -> acorn26
Etoile -> ?
LaCie_NAS -> ?
CL-PS7500 -> ?
Shark -> ?
SA1110-based -> ?
The subarch name will be a little more pervasive than just module
aliasing; it'd get used by boot-floppies, keyboard configuration,
kernel-package, and so on.
My proposal is to keep any hardware designed within running RISC OS
in mind of the form `acorn*'; perhaps as people get RISC OS running
on evermore weird and wonderful hardware this will become less useful.
It'd be nice to fill in the `?'s, but it only really pertains to Debian
at the moment, so it's hardly crucial.
If `netwinder' in fact can be more generic, it would be good to know;
no point forcing lots of people to use `netwinder' later on when it's
inaccurate to their platform.
There is, as far as I can tell, no central implementation of a `subarch
name finder'; boot-floppies, anXious, update-modules, kernel-package,
and so on, all do it individually, their own way. I don't know whether
it's worth trying to go one better than that and provide some sort of
trivial procfs interface for reading subarchitecture names, or have at
least a central stub script to spit the names out, and stick that in
base, or something. <shrug>
Comments appreciated.
(boot-floppies now groks RISC OS disks, for those of you that care.)
c.
--
To UNSUBSCRIBE, email to debian-arm-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: