Re: GEOM weirdness with SD flash reader?

On Mon, 2 Jul 2007, Nate Lawson wrote:

>>>> 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?

This intentionally uncommitted patch comes without warranty, express or 
implied.  :-)

This patch was not intended to solve the problem being discussed here -- it 
was intended to make it easier to write an automounter that responds to 
asynchronous notifications of GEOM-layer events, not deal with the lack of 
asynchronous notifications out of the SCSI and/or hardware to the GEOM layer. 
GEOM relies on these notifications in order to decide when to start the 
"tasting" process, which is why they aren't picked up.  If the SCSI layer does 
discover at some point later when I/O is issued, it does sound like some sort 
of disk_tickle(9) API is required so that SCSI can request a bit of 
reevaluation of matters without actually destroying and recreating the entire 
stack.  I have no opinions about how it should happen if no such asynchronous 
notification is generated by the hardware. :-)

Robert N M Watson
Computer Laboratory
University of Cambridge