Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Fri, 4 Jan 2008, Geert Uytterhoeven wrote:
I totally object to keeping these things around any longer. And this
I support these changes going in.
BTW, I hope you do remember why NCR53C9x.[ch] incarnated in the first
place...
OK, we'll see what we can do...
I have a partially written replacement for mac_esp. Unlike the other
NCR53C9x drivers it needs PIO or pseudo DMA depending on the machine -- so
it is not as straight-forward as jazz_esp. The new esp_scsi core assumes
DMA and doesn't support asynch transfers. But I'll try to get it finished
before 2.6.25 is released.
Finn
Gr{oetje,eeting}s,
Geert
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open-FCoE on linux-scsi
On 1/3/2008 10:58 PM, Love, Robert W wrote: [FUJITA Tomonori wrote] I would add one TODO item, better integration with scsi_transport_fc. If we have HW FCoE HBAs in the future, we need FCoE support in the fc transport class (you could use its netlink mechanism for event notification). What do you have in mind in particular? Our layers are, SCSI Openfc FCoE net_devive NIC driver So, it makes sense to me that we fit under scsi_transport_fc. I like our layering- we clearly have SCSI on our top edge and net_dev at our bottom edge. My initial reaction would be to resist merging openfc and fcoe and creating a scsi_transport_fcoe.h interface. AFAIU the stack should be: - SCSI core, scsi_transport_fc - Openfc (an FCoE implementation) - net_device - NIC driver _If_ there will indeed be dedicated FCoE HBAs in the future, the following stack could exist in addition to the one above: - SCSI core, scsi_transport_fc - FCoE HBA driver(s) -- Stefan Richter -=-==--- ---= --=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Thu, 3 Jan 2008, David Miller wrote:
From: Geert Uytterhoeven [EMAIL PROTECTED]
On Thu, 3 Jan 2008, James Bottomley wrote:
On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote:
As recommended by Christoph Hellwig. There is no use
of Fixing these drivers, since there is a much simpler
and modern esp infrastructure with David Miller's esp_scsi
- Remove all driver files dependent on NCR53C9x.c
deleted:drivers/scsi/NCR53C9x.c
deleted:drivers/scsi/NCR53C9x.h
deleted:drivers/scsi/blz1230.c
deleted:drivers/scsi/blz2060.c
deleted:drivers/scsi/cyberstorm.c
deleted:drivers/scsi/cyberstormII.c
deleted:drivers/scsi/dec_esp.c
deleted:drivers/scsi/fastlane.c
deleted:drivers/scsi/mac_esp.c
deleted:drivers/scsi/mca_53c9x.c
deleted:drivers/scsi/oktagon_esp.c
deleted:drivers/scsi/oktagon_io.S
deleted:drivers/scsi/sun3x_esp.c
- Remove above list from drivers/scsi/Kconfig
drivers/scsi/Makefile
OK, I'll split this into four pieces for scsi-pending, since there are
three separate interest groups with signoffs to collect (MCA, m68k and
alpha) plus the core removal.
Anybody who can look into converting the m68k NCR53C9x drivers and has
hardware to test (some of) them? I don't think we can afford losing one
third of our SCSI drivers...
We can't wait forever, and effort spent maintaining the old
rotting drivers is effort that should instead be spent on
the converted new drivers.
Instead of seeing conversions being written, we've been hearing this
swan song from the m68k crowd forever, it's getting quite old.
quite old == the new esp_scsi arrived in April 2007. On the m68k timescale,
this is just a split-second ago. Following this logic, it's a surprise
OSS hasn't been removed completely ;-)
I totally object to keeping these things around any longer. And this
I support these changes going in.
BTW, I hope you do remember why NCR53C9x.[ch] incarnated in the first place...
OK, we'll see what we can do...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Open-FCoE on linux-scsi
On Thu, 3 Jan 2008 13:58:29 -0800 Love, Robert W [EMAIL PROTECTED] wrote: Talking about stability is a bit premature, I think. The first thing to do is finding a design that can be accepted into mainline. How can we get this started? We've provided our current solution, but need feedback to guide us in the right direction. We've received little quips about libsa and libcrc and now it looks like we should look at what we can move to userspace (see below), but that's all the feedback we've got so far. Can you tell us what you think about our current architecture? Then we could discuss your concerns... I think that you have got littel feedback since few people have read the code. Hopefully, this discussion gives some information. My main concern is transport class integration. But they are just mine. The SCSI maintainer and FC people might have different opinions. 2) Abstractions- We consider libsa a big bug, which we're trying to strip down piece by piece. Vasu took out the LOG_SA code and I'm looking into changing the ASSERTs to BUG_ON/WARN_ONs. That isn't all of it, but that's how we're breaking it down. Agreed, libsa (and libcrc) should be removed. 3) Target- The duplicate code of the target is too much. I want to integrate the target into our -upstream tree. Without doing that, fixes to the -upstream tree won't benefit the target and it will get into worse shape than it already is, unless someone is porting those patches to the target too. I think that ideally we'd want to reduce the target's profile and move it to userspace under tgt. 4) Userspace/Kernel interaction- It's our belief that netlink is the preferred mechanism for kernel/userspace interaction. Yi has converted the FCoE ioctl code to netlink and is looking into openfc next. There are other options and I'm not sure that netlink is the best. I think that there is no general consensus about the best mechanism for kernel/userspace interaction. Even ioctl is still accepted into mainline (e.g. kvm). I expect you get an idea to use netlink from open-iscsi, but unlike open-iscsi, for now the FCoE code does just configuration with kernel/userspace interaction. open-iscsi has non-data path in user space so the kernel need to send variable-length data (PDUs, event, etc) to user space via netlink. So open-iscsi really needs netlink. If you have the FCoE non-data path in user space, netlink would work well for you. We definitely got the netlink direction from open-iscsi. Combining your comment that It's hard to convince the kernel maintainers to merge something into mainline that which can be implemented in user space with If you have the FCoE non-data path in user space, netlink would work well for you, makes it sound like this is an architectural change we should consider. I think they are different topics (though they are related). It's hard to convince the kernel maintainers to merge something into mainline that which can be implemented in user space applies to the target driver. You can fully implement FCoE target software in user space, right? So if so, it's hard to push it into kernel. The trend to push the non-data path to user space applies to the initiator driver. Initiator drivers are expected to run in kernel space but open-iscsi driver was split and the non-data part was moved to user space. The kernel space and user-space parts work together. It's completely different from iSCSI target drivers that can be implemented fully in user space. I'm not sure how strong the trend is though. Is moving non data-path code to userspace a requirement? (you might have answered me already by saying you had 2x failed upstream attempts) I don't know. You need to ask James. I would add one TODO item, better integration with scsi_transport_fc. If we have HW FCoE HBAs in the future, we need FCoE support in the fc transport class (you could use its netlink mechanism for event notification). What do you have in mind in particular? Our layers are, SCSI Openfc FCoE net_devive NIC driver So, it makes sense to me that we fit under scsi_transport_fc. I like our layering- we clearly have SCSI on our top edge and net_dev at our bottom edge. My initial reaction would be to resist merging openfc and fcoe and creating a scsi_transport_fcoe.h interface. As I wrote in another mail, this part is the major issue for me. BTW, I think that the name 'openfc' is a bit strange. Surely, the mainline iscsi initiator driver is called 'open-iscsi' but it doesn't have any functions or files called 'open*'. It's just the project name. Understood, but open-iscsi doesn't have the layering scheme that we do. Since we're providing a Fibre Channel protocol processing layer that different transport types can register with I think the generic name is appropriate. Anyway, I don't think anyone here is terribly stuck on the name; it's not a high priority at this time.
Re: Open-FCoE on linux-scsi
On Fri, 04 Jan 2008 12:45:45 +0100
Stefan Richter [EMAIL PROTECTED] wrote:
On 1/3/2008 10:58 PM, Love, Robert W wrote:
[FUJITA Tomonori wrote]
I would add one TODO item, better integration with scsi_transport_fc.
If we have HW FCoE HBAs in the future, we need FCoE support in the fc
transport class (you could use its netlink mechanism for event
notification).
What do you have in mind in particular? Our layers are,
SCSI
Openfc
FCoE
net_devive
NIC driver
So, it makes sense to me that we fit under scsi_transport_fc. I like our
layering- we clearly have SCSI on our top edge and net_dev at our bottom
edge. My initial reaction would be to resist merging openfc and fcoe and
creating a scsi_transport_fcoe.h interface.
AFAIU the stack should be:
- SCSI core,
scsi_transport_fc
- Openfc (an FCoE implementation)
- net_device
- NIC driver
_If_ there will indeed be dedicated FCoE HBAs in the future, the
following stack could exist in addition to the one above:
- SCSI core,
scsi_transport_fc
- FCoE HBA driver(s)
Agreed. My FCoE initiator design would be something like:
scsi-ml
fcoe initiator driver
libfcoe
fc_transport_class (inclusing fcoe support)
And FCoE HBA LLDs work like:
scsi-ml
FCoE HBA LLDs (some of them might use libfcoe)
fc_transport_class (inclusing fcoe support)
That's the way that other transport classes do, I think. For me, the
current code tries to invent another fc class. For example, the code
newly defines:
struct fc_remote_port {
struct list_head rp_list; /* list under fc_virt_fab */
struct fc_virt_fab *rp_vf; /* virtual fabric */
fc_wwn_trp_port_wwn;/* remote port world wide name */
fc_wwn_trp_node_wwn;/* remote node world wide name */
fc_fid_trp_fid; /* F_ID for remote_port if known */
atomic_trp_refcnt; /* reference count */
u_int rp_disc_ver;/* discovery instance */
u_int rp_io_limit;/* limit on outstanding I/Os */
u_int rp_io_count;/* count of outstanding I/Os */
u_int rp_fcp_parm;/* remote FCP service parameters */
u_int rp_local_fcp_parm; /* local FCP service parameters */
void*rp_client_priv; /* HBA driver private data */
void*rp_fcs_priv; /* FCS driver private data */
struct sa_event_list *rp_events; /* event list */
struct sa_hash_link rp_fid_hash_link;
struct sa_hash_link rp_wwpn_hash_link;
/*
* For now, there's just one session per remote port.
* Eventually, for multipathing, there will be more.
*/
u_char rp_sess_ready; /* session ready to be used */
struct fc_sess *rp_sess; /* session */
void*dns_lookup;/* private dns lookup */
int dns_lookup_count; /* number of attempted lookups */
};
/*
* remote ports are created and looked up by WWPN.
*/
struct fc_remote_port *fc_remote_port_create(struct fc_virt_fab *, fc_wwn_t);
struct fc_remote_port *fc_remote_port_lookup(struct fc_virt_fab *,
fc_fid_t, fc_wwn_t wwpn);
struct fc_remote_port *fc_remote_port_lookup_create(struct fc_virt_fab *,
fc_fid_t,
fc_wwn_t wwpn,
fc_wwn_t wwnn);
The FCoE LLD needs to exploit the exsting struct fc_rport and APIs.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] replace sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE
On Thu, 3 Jan 2008 11:10:04 -0500
Salyzyn, Mark [EMAIL PROTECTED] wrote:
ACK on aacraid/ips/dpt_i2o bits. Inspected others, this patch IS inert.
Thanks!
NitMeBeingStupidAndAddingARiderToTheBill: I know it was a grep/replace.
If you need to respin because of Boaz and do not mind, do not hesitate
to optimize (?) and instead do:
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 70f48a1..c6380c0 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -2298,7 +2298,6 @@ static s32 adpt_i2o_to_scsi(void __iomem *reply,
struct scsi_cmnd* cmd)
// copy over the request sense data if it was a check
// condition status
- if(dev_status == 0x02 /*CHECK_CONDITION*/) {
- u32 len = sizeof(cmd-sense_buffer);
- len = (len 40) ? 40 : len;
+ if (dev_status == 0x02 /*CHECK_CONDITION*/) {
+ u32 len = (SCSI_SENSE_BUFFERSIZE 40) ? 40 :
SCSI_SENSE_BUFFERSIZE;
// Copy over the sense data
memcpy_fromio(cmd-sense_buffer, (reply+28) ,
len);
I see. I'll do if I need to send an updated patch.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
From: Finn Thain [EMAIL PROTECTED] Date: Fri, 4 Jan 2008 22:05:20 +1100 (EST) I have a partially written replacement for mac_esp. Unlike the other NCR53C9x drivers it needs PIO or pseudo DMA depending on the machine -- so it is not as straight-forward as jazz_esp. The new esp_scsi core assumes DMA and doesn't support asynch transfers. But I'll try to get it finished before 2.6.25 is released. It does actually support such things. You can hide it completely your -irq_pending() handler. Process any pending pseudo DMA and return 0 until there is a pseudo DMA error or the pseudo DMA is complete and the ESP is signalling an IRQ. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bsg : Add support for io vectors in bsg
From: Deepak Colluru [EMAIL PROTECTED]
Add support for io vectors in bsg.
Signed-off-by: Deepak Colluru [EMAIL PROTECTED]
---
bsg.c | 52 +---
1 file changed, 49 insertions(+), 3 deletions(-)
diff --git a/block/bsg.c b/block/bsg.c
index 8e181ab..78f47ed 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -245,7 +245,7 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
struct request_queue *q = bd-queue;
struct request *rq, *next_rq = NULL;
int ret, rw;
- unsigned int dxfer_len;
+ unsigned int dxfer_len, iovec_count = 0;
void *dxferp = NULL;
dprintk(map hdr %llx/%u %llx/%u\n, (unsigned long long)
hdr-dout_xferp,
@@ -281,7 +281,31 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
rq-next_rq = next_rq;
dxferp = (void*)(unsigned long)hdr-din_xferp;
- ret = blk_rq_map_user(q, next_rq, dxferp, hdr-din_xfer_len);
+ iovec_count = hdr-din_iovec_count;
+ dxfer_len = hdr-din_xfer_len;
+
+ if (iovec_count) {
+ const int size = sizeof(struct sg_iovec) * iovec_count;
+ struct sg_iovec *iov;
+
+ iov = kmalloc(size, GFP_KERNEL);
+ if (!iov) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ if (copy_from_user(iov, dxferp, size)) {
+ kfree(iov);
+ ret = -EFAULT;
+ goto out;
+ }
+ ret = blk_rq_map_user_iov(q, rq, iov, iovec_count,
+ dxfer_len);
+ kfree(iov);
+ } else {
+ ret = blk_rq_map_user(q, rq, dxferp, dxfer_len);
+ }
+
if (ret)
goto out;
}
@@ -289,14 +313,36 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
if (hdr-dout_xfer_len) {
dxfer_len = hdr-dout_xfer_len;
dxferp = (void*)(unsigned long)hdr-dout_xferp;
+ iovec_count = hdr-dout_iovec_count;
} else if (hdr-din_xfer_len) {
dxfer_len = hdr-din_xfer_len;
dxferp = (void*)(unsigned long)hdr-din_xferp;
+ iovec_count = hdr-din_iovec_count;
} else
dxfer_len = 0;
if (dxfer_len) {
- ret = blk_rq_map_user(q, rq, dxferp, dxfer_len);
+ if (iovec_count) {
+ const int size = sizeof(struct sg_iovec) * iovec_count;
+ struct sg_iovec *iov;
+
+ iov = kmalloc(size, GFP_KERNEL);
+ if (!iov) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ if (copy_from_user(iov, dxferp, size)) {
+ kfree(iov);
+ ret = -EFAULT;
+ goto out;
+ }
+ ret = blk_rq_map_user_iov(q, rq, iov, iovec_count,
+ dxfer_len);
+ kfree(iov);
+ } else {
+ ret = blk_rq_map_user(q, rq, dxferp, dxfer_len);
+ }
if (ret)
goto out;
}
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open-FCoE on linux-scsi
FUJITA Tomonori wrote: Understood, but open-iscsi doesn't have the layering scheme that we do. Since we're providing a Fibre Channel protocol processing layer that different transport types can register with I think the generic name is appropriate. Anyway, I don't think anyone here is terribly stuck on the name; it's not a high priority at this time. open-iscsi provides the proper abstraction. It can handles different transport types, tcp and RDMA (iSER). It supports software iSCSI drivers and HW iSCSI HBAs drivers. They are done via iscsi transport class (and libiscsi). I think I hinted to this offlist, but the bnx2i branch in my iscsi git tree is best to look at for this. The upstream stuff is best the model where we support only HW iscsi hbas drivers (all offload) and SW iscsi drivers (all software). The bnx2i branch modifies the class and lib so it also supports a model in between the two, so pretty much everything is covered. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCH] another SCSI critical bug fix for 2.6.24-rc6
They just keep coming out of the woodwork, sorry. This one's in the
SCSI over RDMA Protocol transport class, so it's causing SCSI over
infiniband installations to oops on shutdown. I'm told that their are
now nearly as many SCSI over IB users as their are voyager users, so,
since it's nearly mainstream, we need to fix the problem urgently ...
The patch is available here:
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
I've just attached it below as well.
James
---
From 911833440b498e3e4fe2f12c1ae2bd44400c7004 Mon Sep 17 00:00:00 2001
From: Dave Dillow [EMAIL PROTECTED]
Date: Thu, 3 Jan 2008 21:34:49 -0500
Subject: [SCSI] SRP transport: only remove our own entries
The SCSI SRP transport class currently iterates over all children
devices of the host that is being removed in srp_remove_host(). However,
not all of those children were created by the SRP transport, and
removing them will cause corruption and an oops when their creator tries
to remove them.
Signed-off-by: David Dillow [EMAIL PROTECTED]
Acked-by: FUJITA Tomonori [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
drivers/scsi/scsi_transport_srp.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/scsi_transport_srp.c
b/drivers/scsi/scsi_transport_srp.c
index 44a340b..65c584d 100644
--- a/drivers/scsi/scsi_transport_srp.c
+++ b/drivers/scsi/scsi_transport_srp.c
@@ -265,7 +265,8 @@ EXPORT_SYMBOL_GPL(srp_rport_del);
static int do_srp_rport_del(struct device *dev, void *data)
{
- srp_rport_del(dev_to_rport(dev));
+ if (scsi_is_srp_rport(dev))
+ srp_rport_del(dev_to_rport(dev));
return 0;
}
--
1.5.3.7
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Open-FCoE on linux-scsi
_If_ there will indeed be dedicated FCoE HBAs in the future, the
following stack could exist in addition to the one above:
- SCSI core,
scsi_transport_fc
- FCoE HBA driver(s)
Agreed. My FCoE initiator design would be something like:
scsi-ml
fcoe initiator driver
libfcoe
fc_transport_class (inclusing fcoe support)
And FCoE HBA LLDs work like:
scsi-ml
FCoE HBA LLDs (some of them might use libfcoe)
fc_transport_class (inclusing fcoe support)
That's the way that other transport classes do, I think. For me, the
current code tries to invent another fc class. For example, the code
newly defines:
struct fc_remote_port {
struct list_head rp_list; /* list under fc_virt_fab */
struct fc_virt_fab *rp_vf; /* virtual fabric */
fc_wwn_trp_port_wwn;/* remote port world wide name
*/
fc_wwn_trp_node_wwn;/* remote node world wide name
*/
fc_fid_trp_fid; /* F_ID for remote_port if known
*/
atomic_trp_refcnt; /* reference count */
u_int rp_disc_ver;/* discovery instance */
u_int rp_io_limit;/* limit on outstanding I/Os */
u_int rp_io_count;/* count of outstanding I/Os */
u_int rp_fcp_parm;/* remote FCP service parameters
*/
u_int rp_local_fcp_parm; /* local FCP service
parameters */
void*rp_client_priv; /* HBA driver private data */
void*rp_fcs_priv; /* FCS driver private data */
struct sa_event_list *rp_events; /* event list */
struct sa_hash_link rp_fid_hash_link;
struct sa_hash_link rp_wwpn_hash_link;
/*
* For now, there's just one session per remote port.
* Eventually, for multipathing, there will be more.
*/
u_char rp_sess_ready; /* session ready to be used */
struct fc_sess *rp_sess; /* session */
void*dns_lookup;/* private dns lookup */
int dns_lookup_count; /* number of attempted lookups
*/
};
/*
* remote ports are created and looked up by WWPN.
*/
struct fc_remote_port *fc_remote_port_create(struct fc_virt_fab *,
fc_wwn_t);
struct fc_remote_port *fc_remote_port_lookup(struct fc_virt_fab *,
fc_fid_t, fc_wwn_t wwpn);
struct fc_remote_port *fc_remote_port_lookup_create(struct fc_virt_fab
*,
fc_fid_t,
fc_wwn_t wwpn,
fc_wwn_t wwnn);
The FCoE LLD needs to exploit the exsting struct fc_rport and APIs.
The openfc is software implementation of FC services such as FC login
and target discovery and it is already using/exploiting existing fc
transport class including fc_rport struct. You can see openfc using
fc_rport in openfc_queuecommand() and using fc transport API
fc_port_remote_add() for fc_rport.
The fcoe module is just a first example of possible openfc transport but
openfc can be used with other transports or HW HBAs also.
The openfc does provide generic transport interface using fcdev which is
currently used by FCoE module.
One can certainly implement partly or fully openfc and fcoe modules in
FCoE HBA.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tgt: Use scsi_init_io instead of scsi_alloc_sgtable
On Thu, 2007-12-13 at 13:44 +0200, Boaz Harrosh wrote:
- If we export scsi_init_io()/scsi_release_buffers() instead of
scsi_{alloc,free}_sgtable() from scsi_lib than tgt code is
much more insulated from scsi_lib changes. As a bonus it will
also gain bidi capability when it comes.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
Acked-by: FUJITA Tomonori [EMAIL PROTECTED]
I'm afraid the reversion of -done removal broke the application of this
yet again ... could you respin.
Thanks,
James
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open-FCoE on linux-scsi
Dev, Vasu wrote: [FUJITA Tomonori wrote:] Agreed. My FCoE initiator design would be something like: scsi-ml fcoe initiator driver libfcoe fc_transport_class (inclusing fcoe support) And FCoE HBA LLDs work like: scsi-ml FCoE HBA LLDs (some of them might use libfcoe) fc_transport_class (inclusing fcoe support) Wouldn't it make more sense to think of fc_transport_class as a FCP layer, sitting between scsi-ml and the various FC interconnect drivers (among them Openfc and maybe more FCoE drivers)? I.e. you have SCSI command set layer -- SCSI core -- SCSI transport layer -- interconnect layer.¹ I am not familiar with FCP/ FCoE/ FC-DA et al, but I guess the FCoE support in the FCP transport layer should then go to the extent of target discovery, login, lifetime management and representation of remote ports and so on as far as it pertains to FCP (the SCSI transport protocol, FC-4 layer) independently of the interconnect (FC-3...FC-0 layers).² [...] The FCoE LLD needs to exploit the exsting struct fc_rport and APIs. The openfc is software implementation of FC services such as FC login and target discovery and it is already using/exploiting existing fc transport class including fc_rport struct. You can see openfc using fc_rport in openfc_queuecommand() and using fc transport API fc_port_remote_add() for fc_rport. Hence, aren't there interconnect independent parts of target discovery and login which should be implemented in fc_transport_class? The interconnect dependent parts would then live in LLD methods to be provided in struct fc_function_template. I.e. not only make full use of the API of fc_transport_class, also think about changing the API _if_ necessary to become a more useful implementation of the interface below FC-4. --- ¹) The transport classes are of course not layers in such a sense that they would completely hide SCSI core from interconnect drivers. They don't really have to; they nevertheless live at a higher level of abstraction than LLDs and a lower level of abstraction than SCSI core. (One obvious example that SCSI core is less hidden than it possibly could be can be seen by the struct fc_function_template methods having struct scsi_target * and struct Scsi_Host * arguments, instead of struct fc_xyz * arguments.) ²) I'm using the term interconnect from the SCSI perspective, not from the FC perspective. -- Stefan Richter -=-==--- ---= --=-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open-FCoE on linux-scsi
Stefan Richter wrote: The interconnect layer could be split further: SCSI command set layer -- SCSI core -- SCSI transport layer (FCP) -- Fibre Channel core -- Fibre Channel card drivers, FCoE drivers. But this would only really make sense if anybody would implement additional FC-4 drivers besides FCP, e.g. RFC 2625, which would also sit on top of Fibre Channel core. PS: There is already an RFC 2625 implementation in Linux, but only for LSIFC9xx. PPS: RFC 2625 is superseded by RFC 4338. -- Stefan Richter -=-==--- ---= --=-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open-FCoE on linux-scsi
Stefan Richter wrote: I.e. you have SCSI command set layer -- SCSI core -- SCSI transport layer -- interconnect layer. The interconnect layer could be split further: SCSI command set layer -- SCSI core -- SCSI transport layer (FCP) -- Fibre Channel core -- Fibre Channel card drivers, FCoE drivers. But this would only really make sense if anybody would implement additional FC-4 drivers besides FCP, e.g. RFC 2625, which would also sit on top of Fibre Channel core. -- Stefan Richter -=-==--- ---= --=-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bsg : Add support for io vectors in bsg
From: Deepak Colluru [EMAIL PROTECTED] Subject: [PATCH] bsg : Add support for io vectors in bsg Date: Fri, 4 Jan 2008 21:47:34 +0530 (IST) From: Deepak Colluru [EMAIL PROTECTED] Add support for io vectors in bsg. Signed-off-by: Deepak Colluru [EMAIL PROTECTED] --- bsg.c | 52 +--- 1 file changed, 49 insertions(+), 3 deletions(-) Thanks, but I have to NACK this. You can find the discussion about bsg io vector support and a similar patch in linux-scsi archive. I have no plan to support it since it needs the compat hack. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Fri, 4 Jan 2008, David Miller wrote: From: Finn Thain [EMAIL PROTECTED] Date: Fri, 4 Jan 2008 22:05:20 +1100 (EST) I have a partially written replacement for mac_esp. Unlike the other NCR53C9x drivers it needs PIO or pseudo DMA depending on the machine -- so it is not as straight-forward as jazz_esp. The new esp_scsi core assumes DMA and doesn't support asynch transfers. But I'll try to get it finished before 2.6.25 is released. It does actually support such things. Does it? When I looked at this around 2.6.22, I found that esp_scsi would always negotiate sync transfers if the target supported that. PIO cannot do sync transfers, so I had to modify esp_scsi in order that the chip's Synchronous Offset register was set to zero (asynch). You can hide it completely your -irq_pending() handler. Process any pending pseudo DMA and return 0 until there is a pseudo DMA error or the pseudo DMA is complete and the ESP is signalling an IRQ. I didn't attempt any processing in irq_pending. I'll look into it. Finn - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
