[lkml]   [2004]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] QStor SATA/RAID driver for 2.6.9-rc3
    James Bottomley wrote:
    > Actually, the driver has no need for a thread at all. Since you're
    > simply using it to fire hotplug events, use schedule_work instead.

    That worries me some, because the mid-layer will perform blocking I/O
    and the like, and I'm not sure how much that stuff may depend on its
    own usage (any?) of workqueues. If you believe it to be safe,
    then I'll nuke the kthread entirely.

    > I also noticed the following in a lightening review:
    > - Kill these constructs:
    > + /* scsi_done expects to be called while locked */
    > + if (!in_interrupt())
    > + spin_lock_irqsave(uhba->lock, flags);
    > scsi_done() doesn't require a lock

    Really? I wonder why the mid-layer is so religious about
    doing the lock around every invocation of it today?

    But again, if we're sure that this is the case, then it certainly
    make's life simpler in the driver.

    > - Your emulated commands assume they're non-sg and issued through the
    > kernel (i.e. you don't kmap and you don't do SG). This will blow up on
    > the first inquiry submitted via SG_IO for instance.

    The SG is tested for and simply failed -- there is no need today for
    SG usage on those code paths. If there turns out to be a need for that
    interface with this driver in the future, we can add it. Just like most
    of the other drivers currently treat it.

    What is the "kmap" semantic, and how should it be applied here?

    Mark Lord
    (hdparm keeper & the original "Linux IDE Guy")
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:06    [W:2.141 / U:0.656 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site