Yes, you're right Lars.

Truly you must publish the IET modifications.

You can isolate the IP portion of your RAIDCore in a separate kernel module and need not publish that, but you must NOT taint the GPL of the iSCSI module.

If the GPL of the iSCSI module is intact, please post the corresponding code and we can help you with it.

If it isn't then here's your chance to fix it so it is before it's released and subject to legal issues.


----- Original Message -----
From: <>
To: <>
Sent: Mon Jul 28 18:43:13 2008
Subject: Re: [Iscsitarget-devel] Integration with RAID Core

On Mon, Jul 28, 2008 at 02:59:21PM -0700, john M wrote:
> Ross,

> Does the File-IO  copy the data-out pdu into the file using generic_file_write
> (which essantially is a memcpy ) ?

> On Mon, Jul 28, 2008 at 2:03 PM, Ross S. W. Walker <>
> wrote:
>     john M wrote:
>     >
>     > Hi Team,
>     >
>     > Can someone put some light on what might be going wrong?
>     Can you put your code up?
>  RAID Core core is IP of my comapny. i can't do that :(

excuse me.

you aparently are modifying iet code.
which is covered by the GPL.

not only can you show those modifications.
you even _have to_.

even if we ignore that for a moment,
it will be very hard to help you with your code, technically,
if the discussion about that code stays in english prose.

>     Would it have been easier/cleaner to create a RAIDCore
>     io type and not messed around with the iscsi processing?

>  I have written the interface which converts the iSCSI Command to RAID Core io
> type.  The Reads are working fine, so are writes also for a particular amount
> of time.  After that it doesn't :(. 
>  I have a interface layer between the IET and RAID Core which would have
> registered itself with RAID Core and also registers itself as RAID IO type with
> IET.  The interface gets a write command, which is given to RAID Core.  The
> RAID Core comes back(Asynchronously) after processing the write command with
> the SGL List which can be filled(DMA'ed) for the write request.  Currently i am
> doing MEMCPY(As i am not having any DMA Engine on my mother board/NIC).  It
> works for a while after that IET starts getting Task Managemnt commands.  Which
> i suspect because of MEMCPY(Which eats up the processor time).
> My Question is Can i DO MEMCPY ?
> if yes what are the sizes for which i can do MEMCPY ?  (As for 512 Bytes write,
> i am seeing this scenerio )
> I see that, in  IET whenever the worker thread picks up the write command, it
> does a FILE WRITE and creats the  response PDU and queues the respose PDU into
> the send queue(Everyhting happens synchronously).  Whereas in my case the
> worker thread pick up the PDU and gives it to RAID CORE and returns.  After a
> while in another thread context(RAID CORE thread context) the response is
> created and the respose PDU is queued into the response queue.  Does this

I may be out of my league here, since I have no contributions to IET.

but, do I understand correctly.

you are developing a boxed product, which will be commercial closed source.

you are trying to tightly integrate IET to give your product just that
competitive performance etch.

you have to modify IET to achieve that.

you run into problems.

but you cannot show those modifications, because that would violate the
protection of your companies "Intellectual Property", so you rather
violate the GPL.

now you ask the very people the Intellectual Property of whom you just
ignored, to help you integrate their GPLed work into your
commercial box product?

I call that bold.

I hope I misunderstood something.


        Lars Ellenberg

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Iscsitarget-devel mailing list

This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.