Re: More leaves on the device tree ?

I think we're getting a little off track of the TODO items
for the inclusion of the usb code.

I think the original post mentions that devinfo(?) works for
the time being, although perhaps some work later on presentation
could be done.

Let's stick with devinfo and hit up the next tasks on the
inclusion list.

I think the next thing is the SMP locking? Or do you have
anything you have in mind from the list you would like to
tackle next?

thank you,
-Alfred



* Hans Petter Selasky <hselasky@xxxxxxx> [071223 00:42] wrote:
On Sunday 23 December 2007, Poul-Henning Kamp wrote:
In message <20071222.234526.246317277.imp@xxxxxxxxxx>, "M. Warner Losh"
writes:
In message: <200712202005.33263.hselasky@xxxxxxx>

Hans Petter Selasky <hselasky@xxxxxxx> 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

--
- Alfred Perlstein
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: klists and struct device semaphores
    ... both the interface and the parent device are locked. ... > the USB bus_type and clear for everything else. ... I think it is fine to lock parent unconditionally. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: About USB composite parent device driver - Usbccgp.sys
    ... yes, usbccgp supports USB SS. ... Please do not send e-mail directly to this alias. ... The driver uses usbccgp.sys as its parent driver. ... Now I got a question about the parent driver that does it support USB selective suspend feature? ...
    (microsoft.public.development.device.drivers)
  • Re: USB bulk transfer help needed
    ... > I have never done USB programing before and nedd a little help. ... each device enumerate recursively it's parent to check if one of it's parent ... You manipulate the device through this interface. ... drivers to manage the most common interfaces, ...
    (microsoft.public.vc.language)
  • Re: USB bulk transfer help needed
    ... >> I have never done USB programing before and nedd a little help. ... > each device enumerate recursively it's parent to check if one of it's ... > drivers to manage the most common interfaces, ...
    (microsoft.public.vc.language)