More leaves on the device tree ?
Hans Petter Selasky
hselasky at c2i.net
Sun Dec 23 00:43:48 PST 2007
On Sunday 23 December 2007, Poul-Henning Kamp wrote:
> In message <20071222.234526.246317277.imp at bsdimp.com>, "M. Warner Losh"
writes:
> >In message: <200712202005.33263.hselasky at c2i.net>
> >
> > Hans Petter Selasky <hselasky at c2i.net> writes:
> >: "make_dev" takes an additional "device_t parent_device" argument and
> >: creates a child device with some magic flags set.
> >
> >What do you do for all the devices in /dev/ for which there is no
> >device_t parent?
Hi,
If the parent is NULL, then no dev_t node is created.
Regarding cloned devices my opinion is that they should always create a
visible entry. What I have done for a while now is to create a dummy dev_t
node. It is so annoying with invisible devices. Then you never know what you
have got. For example "/dev/usbXXX".
What I do is simply to create "/dev/usb0 " with a space in the end. This file
is not openable. Really there sould be a flag for that. Then you
open "/dev/usb0" instead, but this device is never created. That's the clone
device. Then clones appear like "/dev/usb0.XX":
/dev/usb0 % /dev/usb1 % /dev/usb2 % /dev/usb3 %
/dev/usb0.00% /dev/usb1.00% /dev/usb2.00% /dev/usb3.00%
>
> I second Warners comments here.
>
> device_t is a handle for a hardware, dev_t is for a device in /dev,
> they are very different thing and have no reasonable mapping between
> them ([0..N]:[0..M])
I'm not saying that every make_dev() should take a device_t parent. If there
is no "device_t" parent then there will be no node created.
Another approach is to add something like:
void device_enlist_subdev(device_t parent, dev_t sub);
void device_delist_subdev(device_t parent, dev_t sub);
struct device {
...
LIST_HEAD(struct cdev) dv_cdev_children;
...
};
struct cdev {
LIST_ENTRY( .... ) dv_list;
};
For example if you have 8 USB serial port adapters, then you just get 8 TTY
devices like /dev/cuaUXXX . And finding out where the USB devices are
actually connected could be very simple if we could put some hints perhaps in
the device_t tree ?
--HPS
More information about the freebsd-arch
mailing list