[RFC] future IET development

[Arne Redlich-2]

Hi list,

in agreement with Tomo I'd like to accept patches introducing new
features and speed up the merging of these patches a bit, hoping to
encourage new developers / testers.

While I don't intend to apply random patches without reviewing, merging
new features early will inevitably lead to problems / bugs in the
development code, which contradicts our current assertion that trunk
contains the latest and greatest and stable code. I don't want to break
this assertion without asking for user and developer feedback.

My personal preference would be the above scenario of merging new code
to trunk (and temporarily freezing it to stabilize the code for releases
if that turns out to be necessary) over opening a development branch and
merging back and forth between this branch and trunk.

Please let me know your thoughts on this, I appreciate any input.

Thanks,
Arne


-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[rswwalker]

Arne Redlich wrote:

>
> Hi list,
>
> in agreement with Tomo I'd like to accept patches introducing new
> features and speed up the merging of these patches a bit, hoping to
> encourage new developers / testers.
>
> While I don't intend to apply random patches without reviewing,
> merging new features early will inevitably lead to problems / bugs
> in the development code, which contradicts our current assertion
> that trunk contains the latest and greatest and stable code. I don't
> want to break this assertion without asking for user and developer
> feedback.
>
> My personal preference would be the above scenario of merging new code
> to trunk (and temporarily freezing it to stabilize the code for
> releases if that turns out to be necessary) over opening a development
> branch and merging back and forth between this branch and trunk.
>
> Please let me know your thoughts on this, I appreciate any input.

Well I have been waiting patiently for this opportunity...

I agree that the current branch of IET should be feature frozen and
possibly released as 1.0 after some more bug fixing/checking etc.

Once we freeze and release 1.0 I think we should take this opportunity
to branch a new development branch for adding new features to
"modernize" the code.

-Ross

______________________________________________________________________
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.


-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

Am Freitag, den 15.08.2008, 15:59 -0400 schrieb Ross S. W. Walker:

> Arne Redlich wrote:
> >
> > Hi list,
> >
> > in agreement with Tomo I'd like to accept patches introducing new
> > features and speed up the merging of these patches a bit, hoping to
> > encourage new developers / testers.
> >
> > While I don't intend to apply random patches without reviewing,
> > merging new features early will inevitably lead to problems / bugs
> > in the development code, which contradicts our current assertion
> > that trunk contains the latest and greatest and stable code. I don't
> > want to break this assertion without asking for user and developer
> > feedback.
> >
> > My personal preference would be the above scenario of merging new code
> > to trunk (and temporarily freezing it to stabilize the code for
> > releases if that turns out to be necessary) over opening a development
> > branch and merging back and forth between this branch and trunk.
> >
> > Please let me know your thoughts on this, I appreciate any input.
>
> Well I have been waiting patiently for this opportunity...
>
> I agree that the current branch of IET should be feature frozen and
> possibly released as 1.0 after some more bug fixing/checking etc.
>
> Once we freeze and release 1.0 I think we should take this opportunity
> to branch a new development branch for adding new features to
> "modernize" the code.

Putting the 1.0 topic aside for a moment, I think maintaining two
continuous branches and merging selectively, but ultimately  everything
from devel to trunk is too much overhead given our scarce resources.

CMIIW, you seem to want a stable branch that can be pulled from at any
point in time, right? How about creating release branches which will be
maintained until the next release and backport bugfixes from trunk to
the release branch if necessary - comparable to the kernel's -stable
releases?

Cheers,
Arne


-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[rae l]

I care that if IETD has some plan to push the iscsitarget kernel
module (iscsitgt.ko) into the kenrel?

I think the iscsitarget kernel module is stable enough to submit into
the kernel, if it's inlined in the kernel, everything will go better.

Thanks.

On Sat, Aug 16, 2008 at 3:42 AM, Arne Redlich <agr@...> wrote:

> Hi list,
>
> in agreement with Tomo I'd like to accept patches introducing new
> features and speed up the merging of these patches a bit, hoping to
> encourage new developers / testers.
>
> While I don't intend to apply random patches without reviewing, merging
> new features early will inevitably lead to problems / bugs in the
> development code, which contradicts our current assertion that trunk
> contains the latest and greatest and stable code. I don't want to break
> this assertion without asking for user and developer feedback.
>
> My personal preference would be the above scenario of merging new code
> to trunk (and temporarily freezing it to stabilize the code for releases
> if that turns out to be necessary) over opening a development branch and
> merging back and forth between this branch and trunk.
>
> Please let me know your thoughts on this, I appreciate any input.
>
> Thanks,
> Arne
>
>
> -------------------------------------------------------------------------
> 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
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Iscsitarget-devel mailing list
> Iscsitarget-devel@...
> https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel
>

--
Denis Cheng
Linux Application Developer

"One of my most productive days was throwing away 1000 lines of code."
 - Ken Thompson.

-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[rswwalker]

rae l wrote:
>
> I care that if IETD has some plan to push the iscsitarget kernel
> module (iscsitgt.ko) into the kenrel?
>
> I think the iscsitarget kernel module is stable enough to submit into
> the kernel, if it's inlined in the kernel, everything will go better.

IET kernel module will not be included in the base Linux tree.

Other iSCSI modules have been included in the tree, and that is
OK. At least for myself I do not see any real advantage to
inclusion in the tree. If it were, then one would only find it
in the latest kernel versions which one wouldn't see available
in production systems for a number of years. Our development group
is also too small for us to keep on top on the kernel development
as we would need to do if it were included. We are quite happy
keeping IET as a third party utility driver and hope to add
some functionality for distribution maintainers to easily
build packages for IET inclusion (.spec and .deb files).

Going forward, Arne does a brilliant job of keeping informed
of the latest kernel API changes which allows us to keep IET
working on the latest kernels, but we don't shadow the kernel
developments on a day-by-day basis, so we recommend it best
to run IET on mature kernel versions.

-Ross

______________________________________________________________________
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.


-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[rae l]

On Fri, Aug 29, 2008 at 10:38 PM, Ross S. W. Walker
<RWalker@...> wrote:
> rae l wrote:
>>
>> I care that if IETD has some plan to push the iscsitarget kernel
>> module (iscsitgt.ko) into the kenrel?
>>
>> I think the iscsitarget kernel module is stable enough to submit into
>> the kernel, if it's inlined in the kernel, everything will go better.
>
> IET kernel module will not be included in the base Linux tree.

>
> Other iSCSI modules have been included in the tree, and that is
> OK. At least for myself I do not see any real advantage to
> inclusion in the tree. If it were, then one would only find it
> in the latest kernel versions which one wouldn't see available
> in production systems for a number of years. Our development group
> is also too small for us to keep on top on the kernel development
> as we would need to do if it were included. We are quite happy
> keeping IET as a third party utility driver and hope to add
> some functionality for distribution maintainers to easily
> build packages for IET inclusion (.spec and .deb files).
>
> Going forward, Arne does a brilliant job of keeping informed
> of the latest kernel API changes which allows us to keep IET
> working on the latest kernels, but we don't shadow the kernel
> developments on a day-by-day basis, so we recommend it best
> to run IET on mature kernel versions.

Have you read the Documentation/ of the kernel?
Didn't you know the benefits of getting the kernel code into the main
kernel tree?

Here is some reasons from Documentation/stable_api_nonsense.txt:

The very good side effects of having your driver in the main kernel tree
are:
  - The quality of the driver will rise as the maintenance costs (to the
    original developer) will decrease.
  - Other developers will add features to your driver.
  - Other people will find and fix bugs in your driver.
  - Other people will find tuning opportunities in your driver.
  - Other people will update the driver for you when external interface
    changes require it.
  - The driver automatically gets shipped in all Linux distributions
    without having to ask the distros to add it.

First, the demand for one iscsi target code inclusion into the main
kernel tree is ongoing,
We need an iscsi target that can run on as much as possible kernels,
not only the mature kernel versions.
In all kinds of our developments, the iscsi target is one basic
functionality we want, we want iscsi can always be buildable at least,
inclusion into the kernel is the best approach.

Second, I hope there will be more people who are interested in
iscsi-target can test and review IET code, and improve IET to better.
Indeed, in sometimes I observed IET kernel module not very stable on
the latest 2.6.26 and 27-rcX kernels, sometimes it's kernel oops
after serveral stop-ietd-unload-ko-load-ko-start-ietd loops, but not
always reproducible, I'm still tracing on it;
the read-iscsi-consuming-100%-CPU is also another problem we observed
in our lab.
All in one word, I hope more people can lay focus on IET to improve its quality.
If we can improved it to production stable earlier, why not?

Last but not least significant, if you think iscsi target development
group is too small to push the code into main kernel tree,
I can help on this, in fact, I have already a latest
keep-up-with-linus git tree with iet kernel code integrated.
If someone is interested on this, we will collate and publish it some later.

>
> -Ross

Thanks.


--
Denis Cheng
Linux Application Developer

"One of my most productive days was throwing away 1000 lines of code."
 - Ken Thompson.

-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

Am Montag, den 01.09.2008, 01:36 +0800 schrieb rae l:

> Have you read the Documentation/ of the kernel?
> Didn't you know the benefits of getting the kernel code into the main
> kernel tree?
>
> Here is some reasons from Documentation/stable_api_nonsense.txt:

[...]

You can safely assume that we're aware of the benefits of having the
code in the kernel, but it will not happen. It does not make much sense
to merge an iSCSI target into the kernel when there are generic target
frameworks around that can also support different transports such as FC,
FCOE. So there's not the remotest chance of getting IET merged.

Currently there's already STGT code in the kernel. It's basically an
interface for kernel drivers such as FC, however most processing and
many drivers (iSCSI, iSER, FCOE, ...) are done in userspace. And there's
SCST. It also provides several transports and storage backends. It's
mostly implemented in kernel space. Recently there's some movement to
get it into the kernel.

If you're interested in more details just search the linux-scsi and the
respective project's list archives.

> Indeed, in sometimes I observed IET kernel module not very stable on
> the latest 2.6.26 and 27-rcX kernels, sometimes it's kernel oops
> after serveral stop-ietd-unload-ko-load-ko-start-ietd loops, but not
> always reproducible, I'm still tracing on it;

Please post the oops.

Thanks,
Arne


-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel