This patch adds SMP (and UP) support for voyager which is an (up to 32 way)
SMP microchannel non-PC architecture.
There's basically nothing different from the 2.5.15 one except for updates and
changes to the arch-split and a few #include file additions.
The patch is in two parts: The i386 sub-architecture split is separated from
the addition of the voyager components
http://www.hansenpartnership.com/voyager/files/arch-split-2.5.21.diff (165k)
http://www.hansenpartnership.com/voyager/files/voyager-2.5.21.diff (148k)
(The split diff is pretty huge because it's actually moving files about). You
must apply the split diff before applying the voyager one.
These two patches are also available as separate bitkeeper trees (the voyager
tree is a superset of the arch-split one):
http://linux-voyager.bkbits.net/voyager-2.5
http://linux-voyager.bkbits.net/arch-split-2.5
James Bottomley
Attached patch is needed to compile kernel with Voyager patch applied
for the SMP PC machine.
Also some questions, mostly related to arch-split patch:
[Q1] Will it be better to create separate directory for PC architecture
and split some PC'isms from arch/i386/generic ? Right now it contains
acpi.c, bootflag.c and dmi_scan.c which are not generic in any way :)
[Q2] May be directory naming like mach-visws, mach-voyager and possible
mach-pc will be more convinent ?
--
Andrey Panin | Embedded systems software engineer
[email protected] | PGP key: wwwkeys.eu.pgp.net
[email protected] said:
> Attached patch is needed to compile kernel with Voyager patch applied
> for the SMP PC machine.
I've applied it to my repository, thanks. I forgot to keep track of these
issues in the voyager tree when I separated the arch-split stuff.
> [Q1] Will it be better to create separate directory for PC
> architecture and split some PC'isms from arch/i386/generic ? Right now
> it contains acpi.c, bootflag.c and dmi_scan.c which are not generic in
> any way :)
The thinking currently is that arch/i386 is really PC plus a few exceptions
rather than a truly generic x86 plus additonal machine architectures, so it
makes sense under this view that `generic' and PC be the same thing.
> [Q2] May be directory naming like mach-visws, mach-voyager and
> possible mach-pc will be more convinent ?
To be more consistent with the way arch/arm does it? Certainly the renames
can be done easily enough, what does the rest of the list think?
James
[email protected] said:
> Would it make sense for the subarchs to use the generic code where
> possible, and only reimplement it's own (for eg) apic.c as and when it
> actually *needs* to be different ?
That is really the way I've implemented it. The only PC specific file in the
generic directory is mpparse.c (since neither visws nor voyager has an MP
compliant bios). All the shareable files are kept in `kernel' and activated
by config options.
I can certainly move mpparse.c back to kernel and add an extra (non user
visible) config option.
> Sounds quite logical. What does the current patches you have do ? I've
> not had chance to look at them yet.
It creates directories `generic' for the standard pc and `visws'. The voyager
patch creates a `voyager' directory. Alternatively, these could be `mach-pc',
`mach-visws' and `mach-voyager'.
James
[email protected] said:
> IMHO Voyagers are too old and big machines to get (working) APM, and
> visws have no BIOS or limited BIOS emulation.
That depends what you mean by `apm'. In kernel/apm.c, it's tied to the
existence of the APM bios and since voyagers have no bios per say (they
actually have a SUS, which is an actively running boot OS on a tiny i386
processor which can emulate a minimal PC bios when in PC mode) then you're
correct.
Running Linux on a voyager, I can power off the machine, read the internal
power source, the status of the front panel switch and even trigger a power
management shutdown after the AC power is lost for a certain length of time
(voyagers usually have internal lead acid batteries). The way it's currently
set up, if I turn off the front panel switch, the machine will execute a clean
shutdown and power itself off when the shutdown is finished. (this is mainly
done in the voyager_thread.c file, where it keeps a kernel daemon permanently
monitoring the machine status, if you're interested).
The above are all traditional APM functions, I just don't need apm.c to do
them.
However, apm.c is still in arch/i386/kernel, just in case, so I think
mpparse.c should join it, and we should keep all the other pieces (bootflag.c
and acpi.c) in there just in case.
James
[email protected] said:
> "Latest" (2.4.17) visws patch which i'm planning to convert for 2.5,
> uses function MP_processor_info() from generic mpparse.c. May be it
> makes sence to move to some generic file ?
OK, I moved mpparse back into kernel (and gated it on CONFIG_X86_MPPARSE). It
probably makes sense to split it up so that you only get the piece you need
for visws.
I've also done the mach-* renames by popular request. The new patch is at:
http://www.hansenpartnership.com/voyager/files/arch-split-2.5.21-II.diff
and also in the bitkeeper repository:
http://linux-voyager.bkbits.net/arch-split-2.5
James