On Птн, Июн 14, 2002 at 02:45:47 +0200, Dave Jones wrote:
> On Thu, Jun 13, 2002 at 08:13:26PM -0400, James Bottomley wrote:
> > > 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.
>
> Ah, good.
>
> > 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.
>
> Another piece of low hanging fruit is probably dmi_scan.c
> There are no workarounds there for either (are they even DMI compliant?)
> so compiling it in doesn't make much sense.
We also have apm.c, bootflag.c and acpi.c which are definetely PC specific.
> > I can certainly move mpparse.c back to kernel and add an extra (non user
> > visible) config option.
>
> if neither visws or voyager need it, I'd say it doesn't belong in the
> respective subarch directories period.
"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 ?
> > > 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'.
>
> Yeah, I think mach-foo would be more aesthetically pleasing, so I'll
> cast my vote for that one. If nothing else, it makes it obvious that
> the subdir isn't important if you don't care about $subarch
>
> Dave.
--
Andrey Panin | Embedded systems software engineer
[email protected] | PGP key: wwwkeys.eu.pgp.net