API to link sysctl nodes to devices

[KILOREUX Emperex]

Hey,

As part of my participation GSOC, I have been working on an API spec to
link sysctl nodes to devices.

And I cam up with few ideas that I need some feedback on before proceeding
to the implementation on the kernel.

- We need devices to have their propoer sysctl trees, and thus every device
linked will have its own id as the head of its syctl tree.

For example a device with id 0x94, would have it's sysctl root look like
dev.fs.0x94 where the below parameters can be accessed after that.

- We want to give device drivers the ability to create and delete sysctl
nodes as they want, thus proposing a proper interface for it.


So I have been thinking so far to enable the creation of the root for those
sysctl nodes on the system initialization, to allow existing device drivers
to link their device on the tree.

Also we want to propose a new function similar to make_dev, supposed we
name it make_dev_sys, that gets the device id and links it on the tree of
existing sysctl nodes, and for the purpose of keeping track of the
available sysctl nodes for each device, I thought of proposing a change to
the device switching table "cdevsw" to keep systcl context tracked for the
device.

Would any modification to cdevsw break backward compatibility ?
Please provide us with any feedback you have on this proposition and any
defects you seeing in the logic.

Your help is much appreciated.

[Hans Petter Selasky]

Hi,

Post by KILOREUX Emperex
Hey,
As part of my participation GSOC, I have been working on an API spec to
link sysctl nodes to devices.

Can you clarify a bit what you mean by "device". The term "device" was a
bit too generic for me :-) I suppose you mean a "character device", right?

Can you give some examples of properties for a character device, which
can be exposed trough these sysctls you propose ?

Post by KILOREUX Emperex
And I cam up with few ideas that I need some feedback on before proceeding
to the implementation on the kernel.
- We need devices to have their propoer sysctl trees, and thus every device
linked will have its own id as the head of its syctl tree.
For example a device with id 0x94, would have it's sysctl root look like
dev.fs.0x94 where the below parameters can be accessed after that.

Would it be better to have a direct mapping between character device
name, including directories and dev.fs.xxx , like /dev/cuaU0 maps to
dev.fs.cuaU0.xxx ?

Post by KILOREUX Emperex
- We want to give device drivers the ability to create and delete sysctl
nodes as they want, thus proposing a proper interface for it.
So I have been thinking so far to enable the creation of the root for those
sysctl nodes on the system initialization, to allow existing device drivers
to link their device on the tree.
Also we want to propose a new function similar to make_dev, supposed we
name it make_dev_sys, that gets the device id and links it on the tree of
existing sysctl nodes, and for the purpose of keeping track of the
available sysctl nodes for each device, I thought of proposing a change to
the device switching table "cdevsw" to keep systcl context tracked for the
device.
Would any modification to cdevsw break backward compatibility ?
Please provide us with any feedback you have on this proposition and any
defects you seeing in the logic.
Your help is much appreciated.

--HPS

[KILOREUX Emperex]

Hey,

A lot of properties can be easier for other drivers if accessed through
sysctl nodes in a way relate to the device itself, for example, the PCI id
for the device that could be a bit more complex to obtain otherwise.

And for the ID, yeah that seems fine, but what do you think about the
concept in general, got any other way to think about it ? Or do you think I
should approach it any differently ?

Post by Hans Petter Selasky
Hi,

Post by KILOREUX Emperex
Hey,
As part of my participation GSOC, I have been working on an API spec to
link sysctl nodes to devices.

Can you clarify a bit what you mean by "device". The term "device" was a
bit too generic for me :-) I suppose you mean a "character device", right?
Can you give some examples of properties for a character device, which can
be exposed trough these sysctls you propose ?
And I cam up with few ideas that I need some feedback on before proceeding

Post by KILOREUX Emperex
to the implementation on the kernel.
- We need devices to have their propoer sysctl trees, and thus every device
linked will have its own id as the head of its syctl tree.
For example a device with id 0x94, would have it's sysctl root look like
dev.fs.0x94 where the below parameters can be accessed after that.

Would it be better to have a direct mapping between character device name,
including directories and dev.fs.xxx , like /dev/cuaU0 maps to
dev.fs.cuaU0.xxx ?

Post by KILOREUX Emperex
- We want to give device drivers the ability to create and delete sysctl
nodes as they want, thus proposing a proper interface for it.
So I have been thinking so far to enable the creation of the root for those
sysctl nodes on the system initialization, to allow existing device drivers
to link their device on the tree.
Also we want to propose a new function similar to make_dev, supposed we
name it make_dev_sys, that gets the device id and links it on the tree of
existing sysctl nodes, and for the purpose of keeping track of the
available sysctl nodes for each device, I thought of proposing a change to
the device switching table "cdevsw" to keep systcl context tracked for the
device.
Would any modification to cdevsw break backward compatibility ?
Please provide us with any feedback you have on this proposition and any
defects you seeing in the logic.
Your help is much appreciated.

--HPS

[Poul-Henning Kamp]

--------

Post by KILOREUX Emperex
As part of my participation GSOC, I have been working on an API spec to
link sysctl nodes to devices.

It's not really the sysctl nodes as such you should focus on, but
rather on the gap between (the increasingly inaccurately named)
newbus and devfs.

The poster-boy example is how you get from USB bus coordinates to
/dev/da* or /dev/{tty|cua}U* devices.

devd(8) seems to know the linkage and usually I resort to /etc/devd
entries like this to make it liveable:

attach 1000 {
match "device-name" "uftdi[0-9]*";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "ln -s /dev/cua$ttyname /dev/bbb1";
};

notify 1000 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "DETACH";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "rm -f /dev/bbb1";
};

[KILOREUX Emperex]

Hey,

Thanks for your feedback, but we have been over this and what you are
proposing seems pretty interesting, can you please elaborate on how that
could be implemented inside the kernel, or give more details about it, also
it seems a bit cool if we could do both of them together, so what do you
think about sysctl nodes, is there any disadvantages for the implementation
of such API ?

Post by Poul-Henning Kamp
--------
In message <

Post by KILOREUX Emperex
As part of my participation GSOC, I have been working on an API spec to
link sysctl nodes to devices.

It's not really the sysctl nodes as such you should focus on, but
rather on the gap between (the increasingly inaccurately named)
newbus and devfs.
The poster-boy example is how you get from USB bus coordinates to
/dev/da* or /dev/{tty|cua}U* devices.
devd(8) seems to know the linkage and usually I resort to /etc/devd
attach 1000 {
match "device-name" "uftdi[0-9]*";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "ln -s /dev/cua$ttyname /dev/bbb1";
};
notify 1000 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "DETACH";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "rm -f /dev/bbb1";
};
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Warner Losh]

Post by KILOREUX Emperex
Hey,
Thanks for your feedback, but we have been over this and what you are
proposing seems pretty interesting, can you please elaborate on how that
could be implemented inside the kernel, or give more details about it, also
it seems a bit cool if we could do both of them together, so what do you
think about sysctl nodes, is there any disadvantages for the implementation
of such API ?

Post by Poul-Henning Kamp
--------
In message <

Post by KILOREUX Emperex
As part of my participation GSOC, I have been working on an API spec to
link sysctl nodes to devices.

It's not really the sysctl nodes as such you should focus on, but
rather on the gap between (the increasingly inaccurately named)
newbus and devfs.
The poster-boy example is how you get from USB bus coordinates to
/dev/da* or /dev/{tty|cua}U* devices.
devd(8) seems to know the linkage and usually I resort to /etc/devd
attach 1000 {
match "device-name" "uftdi[0-9]*";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "ln -s /dev/cua$ttyname /dev/bbb1";
};
notify 1000 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "DETACH";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "rm -f /dev/bbb1";
};

For /dev/da* we created a geom creation event that should be used instead of a USB insertion event, which removed the strain we had. For uftdi vs ttyUx thing, though, there’s a problem. We could do a device creation event as well (there may already be one), but there’s no way to connect the /dev/ttyUx back to the newbus device_t node, which can be used look up info about the device to do interesting things with. One way to do this would be dev.uftdi.0.%devnodes: ttyU2 ttyU3, which would require some new APIs for adding a dev_t to a device_t. But that might be backwards. I’d like something more like devnode.ttyU2.device: uftdi0 would do the trick (or uftdi.0, since device names can have numbers in them, which is why the sysctl nodes under dev are the way they are). Note ‘devnode’ is just a name, I’m agnostic, but given that dev is already taken (and its an API for many device drivers, so changing it would be difficult) ‘devnode’ seems the next best thing, but I’m open to other names.

Of course, having a stronger coupling between device_t and dev_t would allow us to detect when /dev/foo isn’t destroyed when the device_t created it gets detached.

As for sysctl, there’s already a sysctl tree that’s tightly coupled to a device instance that any device can take advantage of. I’m not sure what you need here, unless it’s what I described in the last paragraph.

Warner

[Poul-Henning Kamp]

--------

Post by Warner Losh
One way to do this would be dev.uftdi.0.%devnodes: ttyU2 ttyU3,
which would require some new APIs for adding a dev_t to a device_t.
But that might be backwards.

Many years ago I hacked up a "newbusfs" prototype, which cdevs under
a device_t named tree in /device, sort of like what Sun did:

/device/nexus0/acpi0/pcib1/xhci0/usbus0/uhub0/uhub3/ucom0 -> /dev/ucom0

I didn't particularly like it, and it doesn't solve the problem IMO,
but it could be one way of doing it.

The opposite would be plan-9 inspiration: Pair all cdevs with a
partner offering the information: /dev/cuaU0 has /dev/cuaU0.info
containing some lines of text with device_t linkage, serial numbers
etc.

Post by Warner Losh
Of course, having a stronger coupling between device_t and dev_t would
allow us to detect when /dev/foo isn't destroyed when the
device_t created it gets detached.

The device_t:dev_t mapping is [0...N]:[0...M], (people tend to forget
things like multihomed disks) so that doesn't really work.

Post by Warner Losh
As for sysctl, there's already a sysctl tree that's
tightly coupled to a device instance that any device can take advantage
of. I'm not sure what you need here, unless it's what I
described in the last paragraph.

I think sysctl needs backpressure, it has exploded from a specialized
place for "root only handles" to a general dumping ground. In
particular it has a useless "all or nothing" attitude to jails.

[Ian Lepore]

Post by Warner Losh

Post by KILOREUX Emperex
Hey,
Thanks for your feedback, but we have been over this and what you are
proposing seems pretty interesting, can you please elaborate on how that
could be implemented inside the kernel, or give more details about it, also
it seems a bit cool if we could do both of them together, so what do you
think about sysctl nodes, is there any disadvantages for the
implementation
of such API ?
On Sat, Jun 4, 2016 at 9:52 AM, Poul-Henning Kamp <

Post by Poul-Henning Kamp
--------
In message <
m>

Post by KILOREUX Emperex
As part of my participation GSOC, I have been working on an API spec to
link sysctl nodes to devices.

It's not really the sysctl nodes as such you should focus on, but
rather on the gap between (the increasingly inaccurately named)
newbus and devfs.
The poster-boy example is how you get from USB bus coordinates to
/dev/da* or /dev/{tty|cua}U* devices.
devd(8) seems to know the linkage and usually I resort to
/etc/devd
attach 1000 {
match "device-name" "uftdi[0-9]*";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "ln -s /dev/cua$ttyname /dev/bbb1";
};
notify 1000 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "DETACH";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "rm -f /dev/bbb1";
};

For /dev/da* we created a geom creation event that should be used
instead of a USB insertion event, which removed the strain we had.
For uftdi vs ttyUx thing, though, there’s a problem. We could do a
device creation event as well (there may already be one), but there’s
no way to connect the /dev/ttyUx back to the newbus device_t node,
which can be used look up info about the device to do interesting
things with. One way to do this would be dev.uftdi.0.%devnodes: ttyU2
ttyU3, which would require some new APIs for adding a dev_t to a
device_t. But that might be backwards. I’d like something more like
devnode.ttyU2.device: uftdi0 would do the trick (or uftdi.0, since
device names can have numbers in them, which is why the sysctl nodes
under dev are the way they are). Note ‘devnode’ is just a name, I’m
agnostic, but given that dev is already taken (and its an API for
many device drivers, so changing it would be difficult) ‘devnode’
seems the next best thing, but I’m open to other names.

We already have all the info you need to get from dev.uftdi.* to the
corresponding /dev/{tty,cua}U# nodes using the ttyname field in the
pnpinfo:

dev.uftdi.0.%pnpinfo: vendor=0x9e88 product=0x9e8f devclass=0x00
devsubclass=0x00 sernum="FTVB685F" release=0x0500 mode=host
intclass=0xff intsubclass=0xff intprotocol=0xff ttyname=U0
ttyports=1

I think it's handled by the ucom (usb_serial) layer so it's the same
for all usb serial adapters. But a similar facility is probably
missing for any other type/class of device.

Also, afaik, there is no easy way to get from /dev/cuaU# to the
corresponding dev.<drivername>.<unit> collection of sysctl info, other
than by iterating the entire dev.* oid hierarchy looking for it.

How about cdev.* as the new top-level oid you propose for linking
character device entries to their related driver oids?

-- Ian

Post by Warner Losh
Of course, having a stronger coupling between device_t and dev_t
would allow us to detect when /dev/foo isn’t destroyed when the
device_t created it gets detached.
As for sysctl, there’s already a sysctl tree that’s tightly coupled
to a device instance that any device can take advantage of. I’m not
sure what you need here, unless it’s what I described in the last
paragraph.
Warner
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "

[KILOREUX Emperex]

cdev as root oid for linking makes a lot of sense yeah, and since the ucom
is handling it for usb serial adapters , I am not sure how a new API could
improve or harm this, since the task description imposes on a specifically
generic API, I would love to hear more about your specific thoughts for how
it should be approached since my mentor is busy :( .

Post by Ian Lepore

Post by Warner Losh

Post by KILOREUX Emperex
Hey,
Thanks for your feedback, but we have been over this and what you are
proposing seems pretty interesting, can you please elaborate on how that
could be implemented inside the kernel, or give more details about it, also
it seems a bit cool if we could do both of them together, so what do you
think about sysctl nodes, is there any disadvantages for the implementation
of such API ?
On Sat, Jun 4, 2016 at 9:52 AM, Poul-Henning Kamp <

Post by Poul-Henning Kamp
--------
In message <
m>

Post by KILOREUX Emperex
As part of my participation GSOC, I have been working on an API spec to
link sysctl nodes to devices.

It's not really the sysctl nodes as such you should focus on, but
rather on the gap between (the increasingly inaccurately named)
newbus and devfs.
The poster-boy example is how you get from USB bus coordinates to
/dev/da* or /dev/{tty|cua}U* devices.
devd(8) seems to know the linkage and usually I resort to /etc/devd
attach 1000 {
match "device-name" "uftdi[0-9]*";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "ln -s /dev/cua$ttyname /dev/bbb1";
};
notify 1000 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "DETACH";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "rm -f /dev/bbb1";
};

For /dev/da* we created a geom creation event that should be used
instead of a USB insertion event, which removed the strain we had.
For uftdi vs ttyUx thing, though, there’s a problem. We could do a
device creation event as well (there may already be one), but there’s
no way to connect the /dev/ttyUx back to the newbus device_t node,
which can be used look up info about the device to do interesting
things with. One way to do this would be dev.uftdi.0.%devnodes: ttyU2
ttyU3, which would require some new APIs for adding a dev_t to a
device_t. But that might be backwards. I’d like something more like
devnode.ttyU2.device: uftdi0 would do the trick (or uftdi.0, since
device names can have numbers in them, which is why the sysctl nodes
under dev are the way they are). Note ‘devnode’ is just a name, I’m
agnostic, but given that dev is already taken (and its an API for
many device drivers, so changing it would be difficult) ‘devnode’
seems the next best thing, but I’m open to other names.

We already have all the info you need to get from dev.uftdi.* to the
corresponding /dev/{tty,cua}U# nodes using the ttyname field in the
dev.uftdi.0.%pnpinfo: vendor=0x9e88 product=0x9e8f devclass=0x00
devsubclass=0x00 sernum="FTVB685F" release=0x0500 mode=host
intclass=0xff intsubclass=0xff intprotocol=0xff ttyname=U0
ttyports=1
I think it's handled by the ucom (usb_serial) layer so it's the same
for all usb serial adapters. But a similar facility is probably
missing for any other type/class of device.
Also, afaik, there is no easy way to get from /dev/cuaU# to the
corresponding dev.<drivername>.<unit> collection of sysctl info, other
than by iterating the entire dev.* oid hierarchy looking for it.
How about cdev.* as the new top-level oid you propose for linking
character device entries to their related driver oids?
-- Ian

Post by Warner Losh
Of course, having a stronger coupling between device_t and dev_t
would allow us to detect when /dev/foo isn’t destroyed when the
device_t created it gets detached.
As for sysctl, there’s already a sysctl tree that’s tightly coupled
to a device instance that any device can take advantage of. I’m not
sure what you need here, unless it’s what I described in the last
paragraph.
Warner
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "

[KILOREUX Emperex]

cdev as root oid for linking makes a lot of sense yeah, and since the ucom
is handling it for usb serial adapters , I am not sure how a new API could
improve or harm this, since the task description imposes on a specifically
generic API, I would love to hear more about your specific thoughts for how
it should be approached since my mentor is busy :( .

Post by Ian Lepore

Post by Warner Losh

Post by KILOREUX Emperex
Hey,
Thanks for your feedback, but we have been over this and what you are
proposing seems pretty interesting, can you please elaborate on how that
could be implemented inside the kernel, or give more details about it, also
it seems a bit cool if we could do both of them together, so what do you
think about sysctl nodes, is there any disadvantages for the implementation
of such API ?
On Sat, Jun 4, 2016 at 9:52 AM, Poul-Henning Kamp <

Post by Poul-Henning Kamp
--------
In message <
m>

Post by KILOREUX Emperex
As part of my participation GSOC, I have been working on an API spec to
link sysctl nodes to devices.

It's not really the sysctl nodes as such you should focus on, but
rather on the gap between (the increasingly inaccurately named)
newbus and devfs.
The poster-boy example is how you get from USB bus coordinates to
/dev/da* or /dev/{tty|cua}U* devices.
devd(8) seems to know the linkage and usually I resort to /etc/devd
attach 1000 {
match "device-name" "uftdi[0-9]*";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "ln -s /dev/cua$ttyname /dev/bbb1";
};
notify 1000 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "DETACH";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "FTHAV9UU";
action "rm -f /dev/bbb1";
};

For /dev/da* we created a geom creation event that should be used
instead of a USB insertion event, which removed the strain we had.
For uftdi vs ttyUx thing, though, there’s a problem. We could do a
device creation event as well (there may already be one), but there’s
no way to connect the /dev/ttyUx back to the newbus device_t node,
which can be used look up info about the device to do interesting
things with. One way to do this would be dev.uftdi.0.%devnodes: ttyU2
ttyU3, which would require some new APIs for adding a dev_t to a
device_t. But that might be backwards. I’d like something more like
devnode.ttyU2.device: uftdi0 would do the trick (or uftdi.0, since
device names can have numbers in them, which is why the sysctl nodes
under dev are the way they are). Note ‘devnode’ is just a name, I’m
agnostic, but given that dev is already taken (and its an API for
many device drivers, so changing it would be difficult) ‘devnode’
seems the next best thing, but I’m open to other names.

We already have all the info you need to get from dev.uftdi.* to the
corresponding /dev/{tty,cua}U# nodes using the ttyname field in the
dev.uftdi.0.%pnpinfo: vendor=0x9e88 product=0x9e8f devclass=0x00
devsubclass=0x00 sernum="FTVB685F" release=0x0500 mode=host
intclass=0xff intsubclass=0xff intprotocol=0xff ttyname=U0
ttyports=1
I think it's handled by the ucom (usb_serial) layer so it's the same
for all usb serial adapters. But a similar facility is probably
missing for any other type/class of device.
Also, afaik, there is no easy way to get from /dev/cuaU# to the
corresponding dev.<drivername>.<unit> collection of sysctl info, other
than by iterating the entire dev.* oid hierarchy looking for it.
How about cdev.* as the new top-level oid you propose for linking
character device entries to their related driver oids?
-- Ian

Post by Warner Losh
Of course, having a stronger coupling between device_t and dev_t
would allow us to detect when /dev/foo isn’t destroyed when the
device_t created it gets detached.
As for sysctl, there’s already a sysctl tree that’s tightly coupled
to a device instance that any device can take advantage of. I’m not
sure what you need here, unless it’s what I described in the last
paragraph.
Warner
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "

[John Baldwin]

Post by KILOREUX Emperex
Hey,
As part of my participation GSOC, I have been working on an API spec to
link sysctl nodes to devices.
And I cam up with few ideas that I need some feedback on before proceeding
to the implementation on the kernel.
- We need devices to have their propoer sysctl trees, and thus every device
linked will have its own id as the head of its syctl tree.
For example a device with id 0x94, would have it's sysctl root look like
dev.fs.0x94 where the below parameters can be accessed after that.
- We want to give device drivers the ability to create and delete sysctl
nodes as they want, thus proposing a proper interface for it.
So I have been thinking so far to enable the creation of the root for those
sysctl nodes on the system initialization, to allow existing device drivers
to link their device on the tree.
Also we want to propose a new function similar to make_dev, supposed we
name it make_dev_sys, that gets the device id and links it on the tree of
existing sysctl nodes, and for the purpose of keeping track of the
available sysctl nodes for each device, I thought of proposing a change to
the device switching table "cdevsw" to keep systcl context tracked for the
device.
Would any modification to cdevsw break backward compatibility ?
Please provide us with any feedback you have on this proposition and any
defects you seeing in the logic.
Your help is much appreciated.

More detail on what you actually want is needed I think. We already have
sysctl device nodes for newbus devices (dev.X.y). The drm2 code insists
on using its own private tree instead of dev.drmn.0.y though which might be
the source of some confusion. If the goal is to know which device_t a
given cdev is associated with, I think having a way to ask that and then use
nodes for the device_t is more straightforward than having an indirection
with a separate sysctl tree with opaque cookies for names.

(That is, if you had a 'QUERY_DEVICET_NAME' ioctl that character device
drivers could optionally implement. Note that only the device driver
really knows the mapping from cdev to device_t. We could perhaps provide
a wrapper where you could add the device_t as an arg via make_dev_s() and
have the devfs ioctl handler handle QUERY_DEVICET_NAME in that layer using
the arg passed to make_dev_s(). I would perhaps have the ioctl return the
name and unit broken out so it is easier to generate the sysctl path.)

[Jean-Sébastien Pédron]

Post by John Baldwin
More detail on what you actually want is needed I think. We already have
sysctl device nodes for newbus devices (dev.X.y).

The main reason behind this project is to be able to implement an
equivalent of Linux' libudev. libudev is based on sysfs to list devices
and query generic or arbitrary informations on those devices.

One consumer of this API on Linux is Mesa, the userland part of the
video drivers providing 3D acceleration and so on. Mesa has a file
descriptor on an entry in /dev (eg. /dev/dri/card0). It passes this file
descriptor to libudev to query informations such as:
o the PCI ID of the graphics card
o the name of the driver ("i915", "nouveau", "radeon", etc.)

Another consumer is libinput, an input stack implementation not tied to
the X.Org server, usable by Wayland compositors. libinput uses libudev
to enumerate input devices and query them, but I never studied what
exactly it needs.

Today, on FreeBSD, Mesa uses the "hw.dri" sysctl tree (which is specific
to graphics card) to get the required informations. But we can't do that
for any kind of devices.

To sum up, we need a way to list devices and get various informations,
in a non-graphics-card-specific way.

There is devinfo(3) but I don't see a way to associate a result from
devinfo(3) to a file descriptor from /dev. Likewise for the "dev" sysctl
tree.

Post by John Baldwin
The drm2 code insists on using its own private tree instead of
dev.drmn.0.y though which might be the source of some confusion.

I agree it should be unifed.

Post by John Baldwin
If the goal is to know which device_t a
given cdev is associated with, I think having a way to ask that and then use
nodes for the device_t is more straightforward than having an indirection
with a separate sysctl tree with opaque cookies for names.
(That is, if you had a 'QUERY_DEVICET_NAME' ioctl that character device
drivers could optionally implement. Note that only the device driver
really knows the mapping from cdev to device_t. We could perhaps provide
a wrapper where you could add the device_t as an arg via make_dev_s() and
have the devfs ioctl handler handle QUERY_DEVICET_NAME in that layer using
the arg passed to make_dev_s(). I would perhaps have the ioctl return the
name and unit broken out so it is easier to generate the sysctl path.)

I see. That's a good idea, thank you! We'll discuss this further.