tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: (Semi-random) thoughts on device tree structure and devfs

On Tue, 9 Mar 2010, David Young wrote:

> On Tue, Mar 09, 2010 at 08:09:57AM +0000, Iain Hibbert wrote:
> > One thing that I think is problematic about trying to do that, is that you
> > might sometimes need to attach a device (allocate the unit number) in
> > order to discover its intrinsic properties. It can't always be done in the
> > attach routine because you might have to wait for a query (or several) to
> > return. For that reason, we should consider that the dv_xname is not
> > necessarily a useful tag.
> >
> > (I say "device" rather than disk because I know that Bluetooth controllers
> > work this way - you can't get the BDADDR until it is up and running)
> I don't understand why the intrinsic properties cannot be found out in
> the match routine, or why waiting for several queries is a problem.

Well, in the case of bt3c(4) it needs to load firmware before you can talk
to it and find out the BDADDR.  So, you also need to access the disk
before it configures..  I don't think the boot up sequence can handle this
scenario as yet?  In that case, the firmware is loaded when the device is
enabled (/etc/rc), not during autoconfig.

But if you want to rewrite the autoconfig mechanism so that each
xxx_attach() function is called in its own kernel thread so that devices
can wait until its safe to load the firmware then I'm all for it.. when do
you plan to allocate the unit number though?


Home | Main Index | Thread Index | Old Index