All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Fredric Isaman <iisaman@citi.umich.edu>
Cc: Jason Glasgow <jglasgow@aya.yale.edu>,
	Christoph Hellwig <hch@infradead.org>,
	Benny Halevy <bhalevy@panasas.com>,
	Andy Adamson <andros@umich.edu>,
	pnfs@linux-nfs.org, linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: [pnfs] [PATCH 05/28] pnfsblock: expose scsi interface
Date: Wed, 12 Mar 2008 20:36:06 +0200	[thread overview]
Message-ID: <47D82296.80002@panasas.com> (raw)
In-Reply-To: <Pine.BSO.4.64.0803121400550.20573@citi.umich.edu>

On Wed, Mar 12 2008 at 20:10 +0200, Fredric Isaman <iisaman@citi.umich.edu> wrote:
> 
> On Wed, 12 Mar 2008, Jason Glasgow wrote:
> 
>> Christoph,
>>
>> Putting device discovery in user space a valid alternative implementation,
>> and we will pursue that model.
>>
>> -Jason
>>
>>
>> On Wed, Mar 12, 2008 at 12:43 PM, Christoph Hellwig <hch@infradead.org>
>> wrote:
>>
>>> On Wed, Mar 12, 2008 at 06:33:34PM +0200, Benny Halevy wrote:
>>>> This calls for a layering violation.
>>>>
>>>> To fill-in more context, here's an excerpt from the next patch,
>>>> showing how you use shost_class to scan all scsi disks:
> 
> The referenced code is an adhoc hack that does what we need it to for now. 
> We would *love* to be able to just call in to some scsi function that fits 
> our needs
> 
>>> Yes, absolutely.  No one outside of few places in the core scsi code
>>> should ever iterate over the scsi disks.
>>>
> 
> Is this for locking reasons?
> 
>>>> My question is how should a proper API between the scsi layer and
>>>> the block layout driver look like?
>>>>
>>>> Can you list your requirements, e.g.:
>>>> - scanning all available devices,
>>>>
>>>> - discovering new devices on the fly
>>>>
>>>> - getting notified for new devices?
>>> Neither.  pnfs shouldn't open block devices from kernelspace at all,
>>> but do it's disovery in userspace.
>>>
> 
> 
> Basically, we are given a disk signature, (an array of offset, byte
> sequence pairs) and want to match it against some visible disk (ignoring
> partitions), or know that it is not currently visible.
> 
> Thus our requirement are:
> 
> Scan all available block devices (though all available SCSI devices is a
> workable substitute).
> 
> Notification of new devices would be a helpful in optimizing rescans for 
> unmapped disk signatures.
> 
> 
> As Jason mentions, we will pursue doing this in userspace.
> 
>  	Fred
> 
> 
OK I found:
#ifndef __i386__
#undef CONFIG_SCSI_OMIT_FLASHPOINT
#define CONFIG_SCSI_OMIT_FLASHPOINT
#endif

try patch below and report
---
BusLogic: Remove total bullshit

Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
---
git-diff --stat -p
 drivers/scsi/BusLogic.h |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/BusLogic.h b/drivers/scsi/BusLogic.h
index bfbfb5c..0f0d7f3 100644
--- a/drivers/scsi/BusLogic.h
+++ b/drivers/scsi/BusLogic.h
@@ -38,11 +38,6 @@
   CONFIG_PCI set.
 */
 
-#ifndef __i386__
-#undef CONFIG_SCSI_OMIT_FLASHPOINT
-#define CONFIG_SCSI_OMIT_FLASHPOINT
-#endif
-
 #ifndef CONFIG_PCI
 #undef CONFIG_SCSI_OMIT_FLASHPOINT
 #define CONFIG_SCSI_OMIT_FLASHPOINT


  reply	other threads:[~2008-03-12 18:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1205263929-8346-1-git-send-email-iisaman@citi.umich.edu>
     [not found] ` <1205263929-8346-2-git-send-email-iisaman@citi.umich.edu>
     [not found]   ` <1205263929-8346-3-git-send-email-iisaman@citi.umich.edu>
     [not found]     ` <1205263929-8346-4-git-send-email-iisaman@citi.umich.edu>
     [not found]       ` <1205263929-8346-5-git-send-email-iisaman@citi.umich.edu>
     [not found]         ` <1205263929-8346-6-git-send-email-iisaman@citi.umich.edu>
2008-03-12 16:33           ` [pnfs] [PATCH 05/28] pnfsblock: expose scsi interface Benny Halevy
2008-03-12 16:43             ` Christoph Hellwig
     [not found]               ` <2ea9cd5a0803121052p6569ff37l26a5448e588407ad@mail.gmail.com>
2008-03-12 18:10                 ` Fredric Isaman
2008-03-12 18:36                   ` Boaz Harrosh [this message]
2008-03-12 20:03                   ` Christoph Hellwig
2008-03-12 20:30                     ` Fredric Isaman
2008-03-12 22:42               ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47D82296.80002@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=andros@umich.edu \
    --cc=bhalevy@panasas.com \
    --cc=hch@infradead.org \
    --cc=iisaman@citi.umich.edu \
    --cc=jglasgow@aya.yale.edu \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pnfs@linux-nfs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.