> Thanks a lot mike, these are mostly acceptable for me.
> >  - Made all the I/O spaces use proper bus resources
> >  - Allocate the resources in machine-dependant code
> I prefer previous patch because most of the code in i386/acpi_machdep.c
> can be shared with IA64 I think.

I'm not so sure about that.  I suspect that the IA64 code is going to be
using the 'generic address' structures and the x-fields in eg. the FACT.
It won't be using the bios signature search either, or the int15
interface.  Realistically, the code in acpi_machdep.c is very simple.a

I also think that if I'm going to continue to use a private identify 
method to attach ACPI (IMO a good idea) then I want to keep its 
implementation as separate from the 'generic' ACPI code as possible.  The 
pmap interface and one checksum routine is all that the current division 
uses, and that's fairly clean.

> >  - Create a machine-dependant "acpiprobe" device which just knows
> >    how to find and set up ACPI for the machine-independant code
> I think only machine-dependant sub-routines should be in acpi_machdep.c,
> the rest common code should be moved back to dev/acpi/acpi.c.
> The first half of acpiprobe_identify() is trying to find rsdp, so
> renaming it to acpi_find_rsdp() (returns struct ACPIrsdp * or NULL),
> moving the rest of acpiprobe_identify() to dev/acpi/acpi.c:acpi_identify()
> and calling acpi_find_rsdp() from acpi_identify() would be better for me.
> acpiprobe_mapmem() seems machine-dependant, so just renaming (acpi_mapmem() ?)
> would be enough.
> acpiprobe_facp(), I think, is MI, should be moved dev/acpi/acpi.c and
> renamed (acpi_find_facp() ?).

That would be possible, but as I mentioned above, adding support for the 
generic-address formats is going to make things *very* messy.

I get a strong feeling that whoever was responsible for making sure that 
ACPI stayed sensible has quit or been fired.  There are a lot of recent 
changes that are just plain *stupid*.

... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to