More leaves on the device tree ?

Hans Petter Selasky hselasky at
Sun Dec 23 00:43:48 PST 2007

On Sunday 23 December 2007, Poul-Henning Kamp wrote:
> In message <20071222.234526.246317277.imp at>, "M. Warner Losh" 
> >In message: <200712202005.33263.hselasky at>
> >
> >            Hans Petter Selasky <hselasky at> 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?


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 ?


More information about the freebsd-arch mailing list