--hI0HXimLkvfVxAyB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 12, 2005 at 02:14:39AM +0100, Martin Husemann wrote:
> On Sat, Nov 12, 2005 at 01:33:11AM +0100, Quentin Garnier wrote:
> >  The reason for that is that the ACPI
> > table itself doesn't carry enough information to allow us to match a
> > device in the ACPI table to a device found by autoconf, and in return,
> > given a device, it's almost impossible to extract its ACPI counterpart.
>=20
> Ok. If that would be solvable, I bet most other problems would have
> easy, obvious solutions.
>=20
> In the OpenFirmware world we face many of the problems you describe, but =
it
> is always very easy to know the firmware device node coresponding to a de=
vice
> you just start to discover in autoconfig. You can then easily walk the OF
> tree around and collect all necessary information "on demand". Everything
> else you can store in device properties and retrieve later (but this
> mostly makes MI drivers live easier, by abstracting MD things into
> abstract properties)

In the ACPI world, the device nodes can have arbitrary names (some
vendors give them human-readable names, such as "PCI0", "USB1", some
prefer concealing them under numbers "C001", "C002").  Not all of them
have explicit types (given by the _HID method):  PCI root buses have the
_HID method, but children buses are combined with their parent bridge,
which has no explicit type but instead might (as in "sometimes not")
have the _PRT method, which is specific to PCI buses.  So given a found
device, it's not possible to retrieve the handle of the matching ACPI
device without already knowing the path of the parent.

But it's also not possible to walk the ACPI namespace first, because
it's not possible either to predict the name of the real device that
will be found:  sometimes there is no actual device, and the lack of
explicit type makes it impossible to tell what driver will attach.
Also, things such as missing _PRT makes it impossible to predict the bus
number of the PCI bus objects until the device is actually attached.

That also means using properties(9) would be hackish, because it is
designed to work with known objects.  I could use it with a "config"
database, and a fixed object "0", but it just would be a hack, as the
config properties don't apply to a real object.  I think the API I
currently have is simple enough for its task.

Now, what should I do with my changes?  Commit the config_env stuff,
then go on with the changes to acpi(4) and pci(4) to use them?  Maybe I
could put all that in a branch so that it is easier to review them and
possibly tweak them a bit before it goes into the trunk?

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--hI0HXimLkvfVxAyB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ3+DldgoQloHrPnoAQIPVQf/QwswX4VxwyxUh3lYeyX+uS70cROwa1q7
GUoIewgusqkzI4LHdS5pbBphwsQHLnCazTs7fpE4DzltdNjlAKVo8gEmT4zhKbaZ
MJX/Qgc1DwM+Hx7q2n0e2MqUO6sDPaimlTUcjL2ANHuDIbqxPooAcfmPUIV/pxKM
VpBaWdAqwbifW70LvWW3KRVqjRQc+IaBkyolErbOYi74/Y4k68mo+12NqzEkYMHW
gE3GTG2QD1vXKMcUCKVIANGZ063HhEzG9cELmfc96ephl9afYpUetO8HZs9eTJD+
pJtNGulNMChNU2fA5PrvyJBEIF3zKpm8ce5cz2VaBfJuKd+1OqCRhQ==
=gt3v
-----END PGP SIGNATURE-----

--hI0HXimLkvfVxAyB--