• James Bottomley's avatar
    Updated state model for SCSI devices · 9b22a8fb
    James Bottomley authored
    I've been looking at enforcing lifetime phases for SCSI devices
    (primarily to try to get the mid layer to offload as much of the device
    creation and hotplug pieces as it can).
    
    I've hijacked the sdev_state field of the struct scsi_device (formerly
    this was a bitmap, now it becomes an enumerated state).
    
    I've also begun adding references sdev_gendev into the code to pin the
    scsi_device---initially in the queue function, but possibly this should
    also be done in the scsi_command_get/put, the idea being to prevent
    scsi_device freeing while there's still device activity.
    
    The object phases I identified are:
    
    1. SDEV_CREATED - we've just allocated the device.  It may respond to
    internally generated commands, but not to user ones (the user should
    actually have no way to access a device in this state, but just in
    case).
    
    2. SDEV_RUNNING - the device is fully operational
    
    3. SDEV_CANCEL - The device is cleanly shutting down.  It may respond to
    internally generated commands (for cancellation/recovery) only; all user
    commands are errored unless they have already been queued (QUEUE_FULL
    handling and the like).
    
    4. SDEV_DEL - The device is gone. *all* commands are errored out.
    
    Ordinarily, the device should move through all four phases from creation
    to destruction, but moving SDEV_RUNNING->SDEV_DEL because of surprise
    ejection should work.
    
    It's starting to look like the online flag should be absorbed into this
    (offlined devices move essentially to SDEV_CANCEL and could be
    reactivated by moving to SDEV_RUNNING).
    
    I haven't altered the similar bitmap model that scsi_host has, although
    this too should probably move to an enumerated state model.
    
    I've tested this by physically yanking a module out from underneath a
    running filesystem with no ill effects (other than a slew of I/O
    errors).
    
    The obvious problem is that this kills possible user error handling, but
    we don't do any of that yet.
    9b22a8fb
scsi.c 30.2 KB