Mike Christie wrote:
For the tasks you want to do for the fc class is performance critical?
No, it should not be.
If not, you could do what the iscsi class (for the netdev people this is
drivers/scsi/scsi_transport_iscsi.c) does and just suffer a couple
copies. For iscsi we do this in
James Smart wrote:
Mike Christie wrote:
For the tasks you want to do for the fc class is performance critical?
No, it should not be.
If not, you could do what the iscsi class (for the netdev people this is
drivers/scsi/scsi_transport_iscsi.c) does and just suffer a couple
copies. For
Mike Christie wrote:
James Smart wrote:
Mike Christie wrote:
For the tasks you want to do for the fc class is performance critical?
No, it should not be.
If not, you could do what the iscsi class (for the netdev people this is
drivers/scsi/scsi_transport_iscsi.c) does and just suffer a
Note: We've transitioned off topic. If what this means is there isn't a good
way except by ioctls (which still isn't easily portable) or system calls,
then that's ok. Then at least we know the limits and can look at other
implementation alternatives.
Mike Christie wrote:
James Smart wrote:
Mike Christie wrote:
James Smart wrote:
Mike Christie wrote:
For the tasks you want to do for the fc class is performance critical?
No, it should not be.
If not, you could do what the iscsi class (for the netdev people this is
drivers/scsi/scsi_transport_iscsi.c) does and just suffer a
James Smart wrote:
Note: We've transitioned off topic. If what this means is there isn't a
good
way except by ioctls (which still isn't easily portable) or system calls,
then that's ok. Then at least we know the limits and can look at other
implementation alternatives.
Mike Christie wrote:
Mike Christie wrote:
James Smart wrote:
Note: We've transitioned off topic. If what this means is there isn't a
good
way except by ioctls (which still isn't easily portable) or system calls,
then that's ok. Then at least we know the limits and can look at other
implementation alternatives.
On Thu, 20 Apr 2006, James Smart wrote:
Note: We've transitioned off topic. If what this means is there isn't a
good
way except by ioctls (which still isn't easily portable) or system calls,
then that's ok. Then at least we know the limits and can look at other
implementation alternatives.
Folks,
To take netlink to where we want to use it within the SCSI subsystem (as
the mechanism of choice to replace ioctls), we're going to need to pass
user-space buffer pointers.
What is the best, portable manner to pass a pointer between user and kernel
space within a netlink message ? The
James Smart wrote:
To take netlink to where we want to use it within the SCSI subsystem (as
the mechanism of choice to replace ioctls), we're going to need to pass
user-space buffer pointers.
What is the best, portable manner to pass a pointer between user and kernel
space within a netlink
Stephen Hemminger wrote:
On Wed, 19 Apr 2006 08:57:25 -0400
James Smart [EMAIL PROTECTED] wrote:
Folks,
To take netlink to where we want to use it within the SCSI subsystem (as
the mechanism of choice to replace ioctls), we're going to need to pass
user-space buffer pointers.
This changes
Patrick McHardy wrote:
This might be problematic, since there is a shared receive-queue in
the kernel netlink message might get processed in the context of
a different process. I didn't find any spots where ISCSI passes
pointers over netlink, can you point me to it?
Please explain... Would
James Smart wrote:
Folks,
To take netlink to where we want to use it within the SCSI subsystem (as
the mechanism of choice to replace ioctls), we're going to need to pass
user-space buffer pointers.
What is the best, portable manner to pass a pointer between user and kernel
space within
13 matches
Mail list logo
