There are (as of now), two issues in the issues file for this case.
Here's a quick response:
gw-1 Do I correctly understand that all the userland stuff such
as hald/dbus, allocate functions the same without change,
but just has more devices that are hot plugable?
Yes, that's the idea. Its possible that I'll discover a problem with
userland (I'm still trying to debug this!) where a userland change might
be necessary, but that would represent a bug in the userland code. (For
example, if it "knows" that "usb" attached devices are hotpluggable, and
doesn't support automatic mount/unmount for normal SCSI hotplug. I'm
hoping that this is not the case. For now it seems mostly not to be,
but I think I'm having some trouble that could be related to failure to
generate appropriate sysevents during hotplug. I'm not sure yet.)
jdc-1 Why does sda_slot_online return no error, but offline does?
(I would have expected the reverse.)
sda_slot_online just notifies the framework to start attempting to use
the slot. The first thing that happens after that is an attempt is made
at card detection, by the framework. That is run asynchronously from
another thread, so there is no good way to report any error back to the
driver. The only failure that could be happen would be a failure in the
driver in any case, so the driver shouldn't call sda_slot_online if it
doesn't believe that the slot is ready for use.
As for sda_slot_offline, the reason I originally had when I wrote the
spec was to allow for failure to be returned if the slot was busy due to
other drivers still using it. However, as I've since learned, this
detection is not necessary, because the DDI framework guards detach
properly to prevent it. In other words, the calling sequence of
xxx_detach() -> sda_slot_offline() is always safe, because xxx_detach()
won't be called at all if there are leaf drivers present. In my current
implementation sda_slot_offline always returns success (0), and really
has no work of its own to do. Here's the current implementation:
int
sda_slot_offline(sda_slot_t *slot)
{
mutex_enter(&slot->s_lock);
slot->s_online = B_FALSE;
mutex_exit(&slot->s_lock);
return (0);
}
As you can see, I could probably just make this a void, and I'm willing
to do that now given my updated understand of detach-safety.
One possible wrinkle in this would be if I added code to the framework
so that the drivers had a cb_ops routine that they were exporting. In
that case, I can see potential for problems, but I think a proper
getinfo(9e) still protects against xxx_detach() getting called in unsafe
situations. (This is unlike my experience with NIC drivers and DLPI
style 2, where inherent races mean you *have* to guard against
improper/unsafe detach, just so you know where I was coming from.)
-- Garrett
