On Wed, 2005-02-16 at 10:57 +1000, Douglas Gilbert wrote:
> "scsi_target: representation of a scsi target, for now,
> this is only used for single_lun devices." This is just above
> the definition of the scsi_target structure in scsi_device.h
Yes, I suppose that's historical junk now.
> Elsewhe
On Tue, 2005-02-15 at 16:54 -0800, Joe Scsi wrote:
> OK (and sorry if I'm being dense) but does this mean that a network
> SCSI transport should make up an "id" for each target port it connects
> to and then call scsi_scan_target()?
Currently yes ... now that we allow unscanned hosts, it's not str
On Tue, 2005-02-15 at 16:53 -0800, Andrew Vasquez wrote:
> Yes, but the parent needs to know if the starget is actually created.
> With the fc_rports snapshot I've been working with, I've coded up the
> following:
Why do you need to know if the scan actually found any LUNs?
>
> + scsi_scan_t
While looking at struct scsi_target in a recent lk 2.6
kernel I was confused by this sentence:
"scsi_target: representation of a scsi target, for now,
this is only used for single_lun devices." This is just above
the definition of the scsi_target structure in scsi_device.h
Elsewhere in that file s
> A driver doesn't allocate a target. In this code, a target device is
> purely a LUN container and is managed by the mid-layer. The driver
> requests the scan of a target by parent device, channel and id. This
> request for a scan creates and parents the target object, but reaps it
> again if n
On Tue, 15 Feb 2005, James Bottomley wrote:
> On Tue, 2005-02-15 at 15:29 -0800, Joe Scsi wrote:
> > I see the internal changes to scsi_scan.c that this refers to, but
> > I'm not totally clear on what a driver should do to allocate a target
> > and scan it when it finds out about a new target por
On Tue, 2005-02-15 at 15:29 -0800, Joe Scsi wrote:
> I see the internal changes to scsi_scan.c that this refers to, but
> I'm not totally clear on what a driver should do to allocate a target
> and scan it when it finds out about a new target port.
A driver doesn't allocate a target. In this code
James, this looks like it would be really useful for my driver and
I hope it goes upstream soon. I do have one question.
> 2. rejig the scanning code to do target scanning via a parent generic
> device rather than the HCTL numbers.
I see the internal changes to scsi_scan.c that this refers to,
Since everyone's been asking for the ability to do target scanning, I
took a look at how this might be done in our current infrastructure.
The attached patch does three things:
1. Pulls target allocation forward so it's now allocated and destroyed
as a separate entity instead of being bound into d
Douglas Gilbert wrote:
Mike Christie wrote:
The attach patch converts scsi_debug to use the virtual scsi bus.
It was built against scsi-rc-fixes-2.6.
The interface has changed a little. Here is an
example of adding and removing a single host:
cd /sys/bus/scsi_host/drivers/scsi_debug
[EMAIL PROTECTE
[this should go to linux-scsi]
> +#include
not needed.
> +#include
I doubt you'll need this one.
> +#include
> +
> +#include /* here are all the ioctls */
should always go before
> +#define MAJOR_NR SCSI_CHANGER_MAJOR
please kill this one
> +#include "scsi.h"
> Can you take a look at the patches I posted last week and see if that
> would work for you?
Hmm, I'm not sure. The issue I have is that I know when target ports
appear and disappear, and I'd like to use some general SCSI midlayer
stuff to discover what LUNs are behind a target port. So if I ha
On Tue, Feb 15, 2005 at 02:33:35PM +, Matthew Wilcox wrote:
> On Tue, Feb 15, 2005 at 12:01:11PM +0200, Meelis Roos wrote:
> > The messages about registration of sda appear tiwice for some reason. This
> > is only cosmetic but still a little strange:
>
> Yes, that happens for everyone.
I pos
On Tue, 2005-02-15 at 14:09 +, Matthew Wilcox wrote:
> Actually, for 53c700, I think this *is* the right fix. Unless we want to
> move it away from using host->base (which is marked as "legacy crap", so
> maybe we do). I guess pushing it into hostdata is the preferred way?
Well, no it's not
On Tue, Feb 15, 2005 at 02:09:02PM +, Matthew Wilcox wrote:
> On Tue, Feb 15, 2005 at 10:39:59AM +, Christoph Hellwig wrote:
> > > - return readb(host->base + (reg^bE));
> > > + return readb((volatile void __iomem *)(host->base + (reg^bE)));
> >
> > Again, no. Stop casting to void __iomem
On Tue, Feb 15, 2005 at 12:01:11PM +0200, Meelis Roos wrote:
> The messages about registration of sda appear tiwice for some reason. This
> is only cosmetic but still a little strange:
Yes, that happens for everyone.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nat
On Tue, Feb 15, 2005 at 10:39:59AM +, Christoph Hellwig wrote:
> > - return readb(host->base + (reg^bE));
> > + return readb((volatile void __iomem *)(host->base + (reg^bE)));
>
> Again, no. Stop casting to void __iomem pointers, please don't submit
> a patch like this one again ever.
Ac
On Mon, Feb 14, 2005 at 08:35:25PM -0800, Joe Scsi wrote:
> Hi,
>
> I'm working on a driver for a SCSI protocol that is transported over a
> network.
> My basic plan is that when the driver is loaded, it will create a SCSI
> host structure
> for its initiator port. Then target ports will be disc
SCSI Enclosure Services (SES) permit "the management and
sense the state of power supplies, cooling devices, displays,
indicators, individual drives, and other non-SCSI elements
installed in an enclosure". The scsi_ses adapter driver
simulates a SES device. The default action is to appear as a
disk
This is 2.6.11-rc4 on Sun SparcStation5 with onbpard ESP scsi, one 2.1G disk
and one cdrom.
The messages about registration of sda appear tiwice for some reason. This is
only cosmetic but still a little strange:
eth0: LANCE 08:00:20:90:36:e5
esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCYC=25000 CCF=8 TOu
20 matches
Mail list logo
