Re: GEOM weirdness with SD flash reader?

Robert Watson wrote:
> 
> On Sun, 1 Jul 2007, Nate Lawson wrote:
> 
>>> : I disagree.  Once scsi_da found the media, it would then somehow
>>> need to
>>> : notify devd (i.e. to automount).  If both functions are in devd, the
>>> : loop becomes:
>>> :
>>> : while (1) {
>>> :     camcontrol tur mydev;
>>> :     if (found)
>>> :         notify_automount;
>>> :         break;
>>> :     sleep 3;
>>> : }
>>>
>>> This doesn't belong in devd.
>>>
>>> Robert has patches to bring new geom entries into the realm of devd.
>>
>> URL?
> 
> This is from quite a long time ago, so likely needs massaging to apply.
> 
>   http://www.watson.org/~robert/freebsd/geom_devctl.diff
> 
> The idea is straight forward: when a new geom device is discovered, we
> issue a notification, which allows devd to respond to events above the
> newbus layer -- i.e., discover of an fdisk partition table, swap-backed
> md device, attachment of a new software RAID layer, arrival of a volume
> by volume name, arrival of a ZFS volume, etc.

Minor comments:
* Functions are small enough that I doubt they need a whole new C file
* devd string looks a little weird ("at on"?)

I don't think this helps.  When usb calls scsi_da calls disk_create(),
userland will get a GEOM devd notice.  Now what happens?

I assume it might be: some script runs, does camcontrol inquiry
<DEVICE>, notes that it is removable, then forks a proc that does the
above sleep loop I described?

I don't think that's any different from what I described except I put it
as internal to devd, not an external script.  I don't care where it goes
so that's fine with me.

After the device is unmounted and the media potentially goes away, who
figures out that the poll loop should start up again?

-- 
Nate