Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757546AbYLMMdb (ORCPT ); Sat, 13 Dec 2008 07:33:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754431AbYLMMdV (ORCPT ); Sat, 13 Dec 2008 07:33:21 -0500 Received: from smtp122.sbc.mail.sp1.yahoo.com ([69.147.64.95]:31816 "HELO smtp122.sbc.mail.sp1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1754226AbYLMMdT (ORCPT ); Sat, 13 Dec 2008 07:33:19 -0500 X-YMail-OSG: 9APPlXwVM1lbfRQTzZTRZehqN_7Ap1R93ztYaEj1kfi9Dm2kkFEvEmYnvcFtof0XDySo9XTf_J8bq.XGMiTdIrX51MJMM8p9fpCTu_5PfnrR5uvraoxvveQyhZPzRDHV7G9MUlKsZZunn6bh0h2sattcQp0XMo6eAf660q09GKH7zf.dsLVC0epUlnZqNqUveTBO9KGet5dHxg6a_TgZDLHIPPW47Tc- X-Yahoo-Newman-Property: ymail-3 Subject: Re: [Announce]: Target_Core_Mod/ConfigFS and LIO-Target v3.0 work From: "Nicholas A. Bellinger" To: Bart Van Assche Cc: linux-iscsi-target-dev@googlegroups.com, LKML , linux-scsi In-Reply-To: References: <1228965271.4153.510.camel@haakon2.linux-iscsi.org> <1229025513.4153.542.camel@haakon2.linux-iscsi.org> <1229074809.4153.666.camel@haakon2.linux-iscsi.org> <54939.1229149205@turing-police.cc.vt.edu> <1229162907.4153.857.camel@haakon2.linux-iscsi.org> <1229167118.4153.930.camel@haakon2.linux-iscsi.org> Content-Type: text/plain Date: Sat, 13 Dec 2008 04:33:17 -0800 Message-Id: <1229171597.4153.981.camel@haakon2.linux-iscsi.org> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5449 Lines: 118 On Sat, 2008-12-13 at 12:56 +0100, Bart Van Assche wrote: > On Sat, Dec 13, 2008 at 12:18 PM, Nicholas A. Bellinger > wrote: > > Of course I fix bugs when people report them. > > Things have changed then since the beginning of this year. As anyone > can see in the threads I referred to, you have done your best to deny > that the crashes and system hangs were caused by LIO, although I had > posted exact instructions on how to reproduce the bugs. Regarding > kernel integration and subsystem maintainership: one of the important > tasks of a maintainer is to verify whether reported bugs are > reproducible, and if so, to resolve them. I'm happy none of the > current kernel maintainers has the habitude of denying bug reports > that are 100% reproducible and which contain exact instructions about > how to reproduce the bug. Heh, so I guess that means that you cannot show me where in lio-core-2.6.git that the issues still exist. Why am I not suprised..? Can you at least even back up your claim that the 10 month old BUGs you posted have not been fixed, or was that just handwaving as well. Again Bart, the only reason took a bit of extra time responding to you because: 1) I was busy helping other people, and 2) The of the disrespectful tone of your emails turns me off If this is the reasoning you cite for ignoring and badmouthing Target_Core_Mod/ConfigFS, LIO-Target v3.0 and myself to the kernel community at large, and making false claims about LIO stability (without looking at an code, by your own admission!?), all I can say is: WoW!! > > > "Zero-copy means that data is copied as few times as possible". > > > > when I was attempting to explain the finer pointers of > > Target_Core_Mod/ConfigFS design to you and Vlad. Remember that one..? > > > > http://groups.google.com/group/linux-iscsi-target-dev/browse_thread/thread/8cff61671cd2de6b/37ade00e607dd8c8 > > You are going off topic -- the above statement has nothing to do with > this thread. > Heh, and posting URLs to 10 month old BUGs that have been fixed 10 months ago in v2.9 on-topic for the Target_Core_Mod/ConfigFS v3.0 discussion..? Like I said, if you would spend a fraction of the time you use trying to discredit LIO code on trying to understand ConfigFS, or my points why I decided not to use SCST as a base for Target_Core_Mod, perhaps you would be apple to make real comments on worthwhile comments here, instead of just your usual handwaving. > Regarding the statement itself: it's incorrect to quote that sentence > out of its context. In that thread, as anyone can see who looks up the > URL, I was using the word copies to refer to transfers between > hardware and RAM, not to copying data from RAM to RAM. Looking at that > statement now I agree that that was misleading, and that I should have > written that statement in another way. > The point is that neither you nor Vlad would acknowledge any of the issues on that thread, or communicate with me in a professional manner without the handwaving. How do you expect me to work with you if you can't even acknowledge the short comings, or offer me a roadmap to get them resolved when all you guys do is handwave..? > Do you think people like it to discuss with you when you try to make > them appear ridiculous all the time ? > I think that your definition of Zero-copy as "data is copied as few times as possible" speaks for itself. I don't exactly know how that can be taken out of context. Of course, that was just the tip of the iceberg on that thread. Lets not even get into how you claimed RDMA meant only userspace ops on virtual memory addresses using a vendor specific API, or that RDMA using virtual addresses would be communicating with drivers/scsi or block/ (which obviously use struct page). So honestly, I was much more concerned about the responses I got from you and Vlad about core SCST core lacking important functionality for $FABRIC_MODs using generic target infrastructure, and your inability to acknowledge anything that you cannot or do not want to understand when it comes to interface with linux storage subsystems in the context on generic target mod. Do you actually think people care about hearing that it look me an extra day to address your issue 10 months ago..? :-) If you honestly think me talking an extra day to address your issue (while I was busy with other things at the same time) has any relivance to the upstream code discussion, your are sorely mistaken. > And what I do not understand is that you are playing games with the CC > list all of the time. It's considered impolite to leave out people > from a CC list unless someone asked explicitly to be left out. > Bart, no one wants to hear us argue, that is why I am saving them the pain and removing them from the CC list. Any until you can start showing me some real techincal content in a professional manner, I am going to simply ignore your clumsy attempts at attacking me and m work. --nab > Bart. > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/