per-device sysctls

[Julian Elischer]

On Thu, 26 Feb 2004, M. Warner Losh wrote:

> In message: <xzp7jy9lmnf.fsf at dwp.des.no>
>             des at des.no (Dag-Erling Sm=F8rgrav) writes:
> : "M. Warner Losh" <imp at bsdimp.com> writes:
> : > How is this different than the sysctl stuff that already exsists for
> : > this and is accessed by devinfo?
> :=20
> :  1) it is immensely easier to access
>=20
> From whose point of view.  devinfo is easier to type than sysctl dev
> by one character :-).  However,

it is easier to check a specific thing..
e.g.  What's on pcibus 2?

sysctl dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2

a bit of a mouthfull, but at least unambiguous :-)
it might be possible to also produce some "more succinct" versions.

i would like to be able to say

sysctl dev.nexus0.acpi0.pcib0.pci0.pcib2.slot2

to see what is there..

This is very close to the device-tree filesystem, (I forget the actual
name) that linux has. The advantage of that approach is that you can
have symlinks..

e.g.

/devtree/nexus0/acpi0/pcib0/pci0/pcib2/pci2/slot2 -->
       /devtree/nexus0/acpi0/pcib0/pci0/pcib2/pci2/bwe0


of course in human terms the above would be easier read as:
/devtree/pcib0/pcib2/slot2
or=20
dev.pcib0.pcib2.slot2

is there a way of getting rid of the "fluff" entries?
( a flag on teh dev_attach saying "I am a fluff entry, do not show me"?)

>=20
> :  2) it gives drivers a well-defined place to put their per-device
> :     sysctl variables - devinfo doesn't address that issue at all
>=20
> That is a good reason to transitioning to this, so long as we can come
> up with a good way to represent detached nodes.  This also gives us a
> good place to hang other actions we may want to send to device drivers
> like power down, etc.

I agree this lays the groundwork for unifying a number of things..

what about 'virtual' devices?

dev.virtual.mem
dev.virtual.mem.size
dev.virtual.kmem

>=20
> Warner
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>=20