Where should devctl notifications be sent from?

[Poul-Henning Kamp]

In message <20040327085537.GC33016 at clan.nothing-going-on.org>, Nik Clayton writ
es:

>It looks like there are several places where the devctl_queue_data() and
>related calls could be placed:
>
>    firewire(4) -- when the device is plugged in
>    fwohci(4) -- when the interface arrives
>    sbp(4) -- when it's recognised as a mass storage device
>    geom(4) -- when geom creates the device (/dev/da2 (and da2s2) in my
>               case).  Robert Watson has a patch that implements this.
>    devfs -- specifically, in make_dev(9) and destroy_dev(9)
>
>The limited research that I've done suggests that the most generic place
>to put this code is inside make_dev(9) and destroy_dev(9).  But this
>seems so trivial that I can't believe no one else hasn't done the work,
>so I figure there's probably something important that I'm missing.

Hehe, this is far from a trivial question :-)

The one question I would like you to answer is:  How do you know it is
the right iPod before you stuff it with you backup ?

The problem is, more or less, that the higher up (ie: lower on your list)
in the kernel you get, the more information you have lost.

Devctl today is working on the newbus view of hardware, and there we
have already lost most of the info that could help you make that
decision.

For disk devices GEOM has mechanisms for querying for out of band data
like serial numbers, but nothing really uses this mechanism yet.

I think that removable disks, as a class, is a sufficiently important
that we probably should give them VIP treatment.   I think this can
be done equally well at GEOM and DEVFS levels, and DEVFS might catch
other currently uncaught devices for us as well.

So, it's not an answer to your question, but at least it narrows down
the doubt a bit.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.