* Re: [Iscsitarget-devel] [RFC] future IET development
[not found] ` <E2BB8074E5500C42984D980D4BD78EF9022A73D4@MFG-NYC-EXCH2.mfg.prv>
@ 2008-08-31 17:36 ` rae l
2008-09-01 5:25 ` Arne Redlich
0 siblings, 1 reply; 2+ messages in thread
From: rae l @ 2008-08-31 17:36 UTC (permalink / raw)
To: Ross S. W. Walker
Cc: Arne Redlich, iscsitarget-devel, linux-kernel, unh-iscsi-checkins
On Fri, Aug 29, 2008 at 10:38 PM, Ross S. W. Walker
<RWalker@medallion.com> 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.
^ permalink raw reply [flat|nested] 2+ messages in thread