Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Andre Hedric » Mon, 06 Jan 2003 04:00:12



Rik and Richard,

As you see, I in good faith prior to this holy war, had initiated a formal
request include a new protocol into the Linux kernel prior to the freeze.
The extention was requested to insure the product was of the highest
quality and not limited with excessive erratium as the ratification of the
IETF modified, postponed, and delayed ; regardless of reason.

Obviously, PyX had (has) on its schedule to product a high quality target
which is transport independent on each side of the protocol.  We are not
sure of this position because of the uncertain nature of the basic usages
of headers and export_symbols.

Regards,

Andre Hedrick, CTO & Founder
iSCSI Software Solutions Provider
http://www.PyXTechnologies.com/

---------- Forwarded message ----------
Date: 23 Oct 2002 09:57:43 +0100



Subject: Re: Linux iSCSI Initiator, OpenSource


> Greetings Linus and Alan,

> PyX Technologies is asking for a formal extention beyond the Oct 31st
> Feature Freeze.  The exception to the rules is generally granted to no
> one, and is well understood by PyX.  Only because PyX is under review for
> full funding on "Oct 31st" in the morning, would I even consider this
> motion.  Our position is to formally open source a full feature with all
> corner cases resolved under "error recovery level zero".

I can't see an iscsi initiator needing to touch core code anyway. Its
just another (slightly demented) scsi adapter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Andrew Morto » Mon, 06 Jan 2003 04:50:07



> Rik and Richard,

> As you see, I in good faith prior to this holy war, had initiated a formal
> request include a new protocol into the Linux kernel prior to the freeze.
> The extention was requested to insure the product was of the highest
> quality and not limited with excessive erratium as the ratification of the
> IETF modified, postponed, and delayed ; regardless of reason.

> Obviously, PyX had (has) on its schedule to product a high quality target
> which is transport independent on each side of the protocol.  We are not
> sure of this position because of the uncertain nature of the basic usages
> of headers and export_symbols.

I suggest that if a function happens to be implemented as an inline
in a header then it should be treated (for licensing purposes) as
an exported-to-all-modules symbol.  So in Linux, that would be LGPL-ish.

The fact that a piece of kernel functionality happens to be inlined
is a pure technical detail of linkage.

If there really is inlined functionality which we do not wish made
available to non-GPL modules then it should be either uninlined and
not exported or it should be wrapped in #ifdef GPL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by NEURONE » Mon, 06 Jan 2003 05:30:09


Quote:> The fact that a piece of kernel functionality happens to be inlined
> is a pure technical detail of linkage.

Absolutely.

Quote:> If there really is inlined functionality which we do not wish made
> available to non-GPL modules then it should be either uninlined and
> not exported or it should be wrapped in #ifdef GPL.

I don't even think there should be any such case,
as the real point in having LGPL is, supposedly, to
support *interfacing*, so using headers (source-code
*interfaces*) and linking to stuff (binding binary
*interfaces*) should be just fine under LGPL (or a
better LGPL? IGPL? dunno the details that deep, sorry).

Sab

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by NEURONE » Mon, 06 Jan 2003 06:20:10


Quote:> > If there really is inlined functionality which we do not wish made
> > available to non-GPL modules then it should be either uninlined and
> > not exported or it should be wrapped in #ifdef GPL.

> I don't even think there should be any such case,
> as the real point in having LGPL is, supposedly, to
> support *interfacing*, so using headers (source-code
> *interfaces*) and linking to stuff (binding binary
> *interfaces*) should be just fine under LGPL (or a
> better LGPL? IGPL? dunno the details that deep, sorry).

(Umm, sorry, I guess I should've been sleeping
fast already, instead of confusing things publicly
here... :-/ )

Sab

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Andre Hedric » Mon, 06 Jan 2003 06:50:06


Andrew et al.,

Now this is a point of responsible policy making, and your previous
position to characterize me as somebody who solely wants to rip off and
use the work of our peers was unwarrented!  Have a glass of milk to help
the crow, trust me it works.

Now the question before developers of "Linux", and not the FSF, GNU
Project, so Richard it has been fun but we shall let you go do what you do
best for now.

Granting special rights to developers is not acceptable, nor would I even
assume or expect to be above the rules.

Grandfathering our design mistakes, and giving notice now that 2.6/3.0
shall have explicit rules and provisions for binary only seems
reasonable.  It would allow time for everyone to get their house in order.
Additionally the developers should not impose restrictions or willfully
change the the current exported_symbols of today for 2.6/3.0 to provide
backwards compatability for another development cycle.

If the kernel developers force out all current binary only vendors of
today now, the ramp up and recovery time to support our current shortages
is incredible and steep.

I will have to take a calculated risk of exposure and trust our peers are
reasonable and will not seek to destroy one another.

Just to let you all in on the scope of the project, I am hoping to empower
all the folks who have shipped and promoted Linux on the hardware side.
Yeah, I mean all the white box builders who are having it as rough as
everyone else.  The big storage vendors are users-keepers of all of our
hard work.  iSCSI is the first time Enterprise storage is not controlled
by the few and the powerful who are basically untouchable.

I have a goal and a vision to enable Linux to dominate the Enterprise
Storage arena and do it in a cost effective manner.  The time is now as
the hardware vendors who will only ship binary modules and look to other
architects to embed the protocol.

If you are against this idea of bringing enterprise storage to the masses,
under Linux, I will be forced to migrate the most valuable piece of IP to
another platform.  To give each of you an idea how much work is involved
to achieve interoperability ...

http://www.PyXTechnologies.com/target.html

This is a snapshot of MicroSoft NT4+SP6 running on a Dell Beetle Box.
The initiator is the IBM v8 1.2.2 windows initiator.
The target is PyX-Target using 3ware 8500-8 SATA with 6 Maxtor 160/5400.
The benchmark is Intel's IOmeter.
I have no control of the initiator environment :-/

The image break down goes as the following.

                        Random Access | Sequential Access
                        ---------------------------------
 67% read,  33% write  | 112 MB/sec   | 112 MB/sec
  0% read, 100% write  |  69 MB/sec   |  69 MB/sec
100% read,   0% write  | 180 MB/sec   | 171 MB/sec

I can make this an absolute win for Linux from my side.

The strenght of Dave Miller and Jeff Garzik on the netork stack for TOE's.
The vision of Jens Axboe to deploy BIO successfully.
The stomachs of James Bottomley and Douglas Gilbert to fix SCSI.
The insanity of Rik van Riel, Andrea Arcangeli, yourself for MM.
The new RAID 6 by H. Peter Anvin.
Plus the MD/LVM gang.
With grit of Alex Viro to keep us all straight!

It takes all of us, all of you, and more to make Linux the the absolute
winner take all in the future of enterprise storage.

---------

I am either in or out, but I will not risk loosing the ability to recover
all of my development costs and fill the bank account first before I give
it up and grab the next generation of storage technology roller coaster in
another three years.  There are three levels of Error Recovery, and one
released a year is reasonable to me.  That implies, I could publish ERL=0
today before I have recovered a DIME, with 18 months in the hole now.

Again all I want to know is where the threshold of fair usage lays.

This posting made by Linus to the gnu.misc.discuss newsgroup (Message-ID

basically gave his permission for the EXPORT_SYMBOL
vs. EXPORT_SYMBOL_GPL system hereby proprietary modules that call only
EXPORT_SYMBOL symbols are allowed:

http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaava.helsi...

Until there is some type of agreement ratified by all of us, this is a
safe position for setting and holding a precedence.  If any one of the
copyright holders in the kernel wishes to formally object, please do so
now.  If you are not one of these people I would ask you to hold your
comments, because FSF has "released" responsiblity of enforcement to them.
Please respect my request.

Regards,

Andre Hedrick, CTO & Founder
iSCSI Software Solutions Provider
http://www.PyXTechnologies.com/



> > Rik and Richard,

> > As you see, I in good faith prior to this holy war, had initiated a formal
> > request include a new protocol into the Linux kernel prior to the freeze.
> > The extention was requested to insure the product was of the highest
> > quality and not limited with excessive erratium as the ratification of the
> > IETF modified, postponed, and delayed ; regardless of reason.

> > Obviously, PyX had (has) on its schedule to product a high quality target
> > which is transport independent on each side of the protocol.  We are not
> > sure of this position because of the uncertain nature of the basic usages
> > of headers and export_symbols.

> I suggest that if a function happens to be implemented as an inline
> in a header then it should be treated (for licensing purposes) as
> an exported-to-all-modules symbol.  So in Linux, that would be LGPL-ish.

> The fact that a piece of kernel functionality happens to be inlined
> is a pure technical detail of linkage.

> If there really is inlined functionality which we do not wish made
> available to non-GPL modules then it should be either uninlined and
> not exported or it should be wrapped in #ifdef GPL.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Andrew Morto » Mon, 06 Jan 2003 08:20:05



> ..
> Again all I want to know is where the threshold of fair usage lays.

Yes, it needs to be clarified.

> This posting made by Linus to the gnu.misc.discuss newsgroup (Message-ID

> basically gave his permission for the EXPORT_SYMBOL
> vs. EXPORT_SYMBOL_GPL system hereby proprietary modules that call only
> EXPORT_SYMBOL symbols are allowed:

> http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaava.helsi...

I wasn't aware of that posting until Adam pointed it out.  It seems
to be a sensible and easily understandable position.

Quote:> Until there is some type of agreement ratified by all of us, this is a
> safe position for setting and holding a precedence.  If any one of the
> copyright holders in the kernel wishes to formally object, please do so
> now.

Yup.  Now is their chance.  Is everyone OK with treating the contents
of header files in the same was as EXPORT_SYMBOL()?  ie: LGPL?

Really, I don't see any alternative.  Even things like the semaphore
down() function are inlined.  Linus's 1995 intentions are infeasible
unless we also treat that part of the kernel API which is implemented
in headers as being exported.

It might make sense to be more selective, by putting #ifdef GPL around
some portions.  If anyone cares, and can be bothered.  If any inlined
function is complex enough to justify that then it's too damn big and
should be zoomed into a .c file anyway.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Adam J. Richte » Tue, 07 Jan 2003 01:00:09


Quote:Andrew Morton writes:
>Is everyone OK with treating the contents
>of header files in the same was as EXPORT_SYMBOL()? ie: LGPL?

        I don't believe that anyone other than Linus has explicity
given their permission for the "EXPORT_SYMBOL_GPL / EXPORT_SYMBOL"
system.  However, I'm not trying to obstruct other people giving
what permissions they want with the code that they wrote, so I'd
like to point out a problem and suggest a fix to your proposal.

        Your proposal would prevent "EXPORT_SYMBOL_GPL" inline
functions.

        I can think of a solution which would
                (1) allow both kinds of functions and
                (2) which I think would be more legally defensible than
                    posting a message to a mailing list and asking "is
                    everyone OK with it]".

        Have the appropriate copyright owners move their "proprietary
callers OK" inline functions to files with the appropriate copyright
statements (such as LGPL or something similar), or submit changes to
the copyright statements of entire .h files in cases where you've got
the explicit agreement of all the copyright owners for that file.

        Along the same lines, those copyright owners (individuals,
companies, etc.) who seek to create a kernel that contains only
content that allows proprietary modules could start by explicitly
stating that they now irrevocably give the same permission that Linus
gave in his gnu.misc.discuss posting for their past contributions and
any future contributions that they make before they say otherwise.  At
least socially, it would come with better graces for people to grant
permissions on their copyrights before trying to interpret away other
contributors' copyrights.

        However, before you grant such permission, I recommend that
you consider whether permission that allows proprietary linking
against only EXPORT_SYMBOL functions really means allowing proprietary
modules to call *all* functions by just including a GPL-compatible
library module like so:

void loophole_ide_setup_pci_device (struct pci_dev *dev, ide_pci_device_t *d)
{
        return ide_setup_pci_device(dev, d);
        /* ide_setup_pci_device is an EXPORT_SYMBOL_GPL function in 2.5.54. */

Quote:}

EXPORT_SYMBOL(loophole_pci_hp_register);

        One could presumably do the same with an function that is not
even exported, and perhaps even avoid the subroutine jump by using
static inline declarations.  As far as I can tell, it would be
essentially equivalent to switching to the LGPL.  Come to think of it,
if this _is_ what you want, then maybe you find it simpler to just
grant permission to copy your code under the LGPL.

        I'm not a lawyer, so don't take this is as legal advice.

Adam J. Richter     __     ______________   575 Oroville Road

+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Oliver Xymoro » Tue, 07 Jan 2003 05:10:06




> > Rik and Richard,

> > As you see, I in good faith prior to this holy war, had initiated a formal
> > request include a new protocol into the Linux kernel prior to the freeze.
> > The extention was requested to insure the product was of the highest
> > quality and not limited with excessive erratium as the ratification of the
> > IETF modified, postponed, and delayed ; regardless of reason.

> > Obviously, PyX had (has) on its schedule to product a high quality target
> > which is transport independent on each side of the protocol.  We are not
> > sure of this position because of the uncertain nature of the basic usages
> > of headers and export_symbols.

> I suggest that if a function happens to be implemented as an inline
> in a header then it should be treated (for licensing purposes) as
> an exported-to-all-modules symbol.  So in Linux, that would be LGPL-ish.

> The fact that a piece of kernel functionality happens to be inlined
> is a pure technical detail of linkage.

> If there really is inlined functionality which we do not wish made
> available to non-GPL modules then it should be either uninlined and
> not exported or it should be wrapped in #ifdef GPL.

More pragmatically, who cares? There's already at least one vendor
(Cisco) who ships a perfectly good fully GPLed iSCSI initiator module
that doesn't need to touch any core code. It's already the benchmark
for compatibility at interoperability tests. And it's following the
IETF drafts closely too. Once we actually have an iSCSI RFC, it might
be worth pulling it into the kernel tree. I believe Red Hat is
shipping it some form already.

That leaves the question of using Linux as an iSCSI target, and I've
yet to see any reason why this couldn't be done in userspace. In fact,
in a lot of ways that's the right thing to do as it lets you take
proper advantage of MD/LVM/EVMS/crypto, etc..

There are a few other free implementations out there too.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Richard Stallma » Tue, 07 Jan 2003 05:40:05


    I suggest that if a function happens to be implemented as an inline
    in a header then it should be treated (for licensing purposes) as
    an exported-to-all-modules symbol.  So in Linux, that would be LGPL-ish.

The Linux developers can certainly do this, if the copyright holders
of the substantial functions in question go along with it.  Even if
they already went along with linking to their functions from non-free
modules, this is still somewhat different.

The question only arises for the specific non-small functions that are
to be inlined in headers in this way.  (Inlining a very small function
from a header is probably not significant for copyright.)  Perhaps the
copyright holders of these functions are few and easy to ask.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Andre Hedric » Tue, 07 Jan 2003 05:50:04





> > > Rik and Richard,

> > > As you see, I in good faith prior to this holy war, had initiated a formal
> > > request include a new protocol into the Linux kernel prior to the freeze.
> > > The extention was requested to insure the product was of the highest
> > > quality and not limited with excessive erratium as the ratification of the
> > > IETF modified, postponed, and delayed ; regardless of reason.

> > > Obviously, PyX had (has) on its schedule to product a high quality target
> > > which is transport independent on each side of the protocol.  We are not
> > > sure of this position because of the uncertain nature of the basic usages
> > > of headers and export_symbols.

> > I suggest that if a function happens to be implemented as an inline
> > in a header then it should be treated (for licensing purposes) as
> > an exported-to-all-modules symbol.  So in Linux, that would be LGPL-ish.

> > The fact that a piece of kernel functionality happens to be inlined
> > is a pure technical detail of linkage.

> > If there really is inlined functionality which we do not wish made
> > available to non-GPL modules then it should be either uninlined and
> > not exported or it should be wrapped in #ifdef GPL.

> More pragmatically, who cares? There's already at least one vendor
> (Cisco) who ships a perfectly good fully GPLed iSCSI initiator module
> that doesn't need to touch any core code. It's already the benchmark
> for compatibility at interoperability tests. And it's following the
> IETF drafts closely too. Once we actually have an iSCSI RFC, it might
> be worth pulling it into the kernel tree. I believe Red Hat is
> shipping it some form already.

If you know anything about iSCSI RFC draft and how storage truly works.
Cisco gets it wrong, they do not believe in supporting the full RFC.
So you get ERL=0, and now they turned of the "Header and Data Digests",
this is equal to turning off the iCRC in ATA, or CRC in SCSI between the
controller and the device.  For those people who think removing the
checksum test for the integrity of the data and command operations, you
get what you deserve.

Quote:> That leaves the question of using Linux as an iSCSI target, and I've
> yet to see any reason why this couldn't be done in userspace. In fact,
> in a lot of ways that's the right thing to do as it lets you take
> proper advantage of MD/LVM/EVMS/crypto, etc..

You go right ahead, and see if you can move at near wire speed.
Next try to support any filesystem regardless of platform.
Specifically anything Microsoft does to thwart Linux, I have already
covered.

Quote:> There are a few other free implementations out there too.

Please go use them and in two seconds my product can bring them all to the
ground with the full error injection tool kit from both sides.  My team
has gone through supporting every optional feature in the RFC draft as
manditory to remove any possible vendor unique opportunities.

There are grey areas in the RFC draft to support every corner case of
ERL=1 and ERL=2.

You figure out how to support the marker stream to perform a
Sync-and-Steering layer.

PyX is the second in the world to support Sync-and-Steering, and the first
to do it software only.

Please go for it, and you will spend at least 18-24 months to develop.

The target(erl=0) is what would be the second phase to open source, but I
see you and other want to do the hard way and that is fine.

In two week I will have NetBSD certified, and 4 weeks later should have
Solaris certifed.

Cheers,

Andre Hedrick, CTO & Founder
iSCSI Software Solutions Provider
http://www.PyXTechnologies.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Andre Hedric » Tue, 07 Jan 2003 06:20:06


Richard,

Can you admit the follow, that GPL has everything to control
redistribution, and has ZERO context for copyright.  The holders of the
copyright control the issues.

See your whole hook is "Derivative Works" well, I implimented a protocol.
It works regardless of platform or OS.  All it uses are simple and
standard kernel services.

Since I am willing to list every kernel function I call, and see who is
going to object to me doing what everyone else is doing and is clearly
positioned as accepted as of 1995.  If you were not aware of this
position, and I was not either, tough.  Linus sets the rules and he
controls the key interfaces.

Next you have NO ownership in the kernel, so unless you try to collect a
group of copyright holders and advocate on their behalf, I think you are
way out of bounds to even be here, period.  As you have stated already,
this is an issue exclusive to the copyright holders, and you are not one
of us.  So please live by your own words, or state you legal position to
be here in the affairs of the Copyright holders.

Regards,

Andre Hedrick, CTO & Founder
iSCSI Software Solutions Provider
http://www.PyXTechnologies.com/


>     I suggest that if a function happens to be implemented as an inline
>     in a header then it should be treated (for licensing purposes) as
>     an exported-to-all-modules symbol.  So in Linux, that would be LGPL-ish.

> The Linux developers can certainly do this, if the copyright holders
> of the substantial functions in question go along with it.  Even if
> they already went along with linking to their functions from non-free
> modules, this is still somewhat different.

> The question only arises for the specific non-small functions that are
> to be inlined in headers in this way.  (Inlining a very small function
> from a header is probably not significant for copyright.)  Perhaps the
> copyright holders of these functions are few and easy to ask.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Oliver Xymoro » Tue, 07 Jan 2003 07:30:11






> > > > Rik and Richard,

> > > > As you see, I in good faith prior to this holy war, had initiated a formal
> > > > request include a new protocol into the Linux kernel prior to the freeze.
> > > > The extention was requested to insure the product was of the highest
> > > > quality and not limited with excessive erratium as the ratification of the
> > > > IETF modified, postponed, and delayed ; regardless of reason.

> > > > Obviously, PyX had (has) on its schedule to product a high quality target
> > > > which is transport independent on each side of the protocol.  We are not
> > > > sure of this position because of the uncertain nature of the basic usages
> > > > of headers and export_symbols.

> > > I suggest that if a function happens to be implemented as an inline
> > > in a header then it should be treated (for licensing purposes) as
> > > an exported-to-all-modules symbol.  So in Linux, that would be LGPL-ish.

> > > The fact that a piece of kernel functionality happens to be inlined
> > > is a pure technical detail of linkage.

> > > If there really is inlined functionality which we do not wish made
> > > available to non-GPL modules then it should be either uninlined and
> > > not exported or it should be wrapped in #ifdef GPL.

> > More pragmatically, who cares? There's already at least one vendor
> > (Cisco) who ships a perfectly good fully GPLed iSCSI initiator module
> > that doesn't need to touch any core code. It's already the benchmark
> > for compatibility at interoperability tests. And it's following the
> > IETF drafts closely too. Once we actually have an iSCSI RFC, it might
> > be worth pulling it into the kernel tree. I believe Red Hat is
> > shipping it some form already.

> If you know anything about iSCSI RFC draft and how storage truly works.
> Cisco gets it wrong, they do not believe in supporting the full RFC.
> So you get ERL=0, and now they turned of the "Header and Data Digests",
> this is equal to turning off the iCRC in ATA, or CRC in SCSI between the
> controller and the device.  For those people who think removing the
> checksum test for the integrity of the data and command operations, you
> get what you deserve.

CRC code seems to be functional, at least in their most recent drop.
As for ERL, the state of error handling in the rest of the Linux IO
layer suggests that's a lower triage priority..

If and when it becomes a high priority, well, the community is free to do what
it likes with the source.

Quote:> Next try to support any filesystem regardless of platform.
> Specifically anything Microsoft does to thwart Linux, I have already
> covered.

I'm having a very hard time making any sense of that statement.
There's no reason an iSCSI initiator on the MS side should care what
OS is serving it iSCSI. And the target shouldn't give a damn whether
it's serving up a filesystem.

Quote:> The target(erl=0) is what would be the second phase to open source, but I
> see you and other want to do the hard way and that is fine.

> In two week I will have NetBSD certified, and 4 weeks later should have
> Solaris certifed.

Frankly, I think you're the one choosing the hard path. Proprietary
code is the domain of corporate giants and you're likely to get
squished - marketing matters more than quality. If you choose to go
that road, I wish you the best of luck.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Lincoln Dal » Tue, 07 Jan 2003 09:20:06


Andre,


Quote:>If you know anything about iSCSI RFC draft and how storage truly works.
>Cisco gets it wrong, they do not believe in supporting the full RFC.

i can tell you that you're mistaken in your belief.

[..]

Quote:>Next try to support any filesystem regardless of platform.
>Specifically anything Microsoft does to thwart Linux, I have already
>covered.

you seem to miss the basic fact that iSCSI is a block-layer
transport.  file system != block layer.
supporting any filesystem with iSCSI is trivial - its just the same as
supporting any filesystem on any other block device.

[..]

Quote:>In two week I will have NetBSD certified, and 4 weeks later should have
>Solaris certifed.

we certainly don't care about any "certifications" you have for NetBSD or
solaris.

if you wish to discuss the various merits of parts of the iSCSI protocol,
there are forums for that kind of thing.
linux-kernel is not one of them.

cheers,

lincoln.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)

Post by Andre Hedric » Tue, 07 Jan 2003 10:00:13



> Andre,


> >If you know anything about iSCSI RFC draft and how storage truly works.
> >Cisco gets it wrong, they do not believe in supporting the full RFC.

> i can tell you that you're mistaken in your belief.

So Cisco now will turn on and leave the Header and Data Digests on, this
differs from your last initiator test.

Quote:> [..]
> >Next try to support any filesystem regardless of platform.
> >Specifically anything Microsoft does to thwart Linux, I have already
> >covered.

> you seem to miss the basic fact that iSCSI is a block-layer
> transport.  file system != block layer.
> supporting any filesystem with iSCSI is trivial - its just the same as
> supporting any filesystem on any other block device.

No, you just lost the context of Oliver's question about doing it all from
user space.  Whereas it could be suggested "a target" drops in to the
respective builting FS support.  Why, because attempting to bypass the
double memcpy to/from user/kernel space.

Since it is a pure "block-transport", and execution the raw data transport
to the spindle, the stack does not care about anything about.  Block is a
bit-bucket as what defines SAN.

Quote:> [..]
> >In two week I will have NetBSD certified, and 4 weeks later should have
> >Solaris certifed.

> we certainly don't care about any "certifications" you have for NetBSD or
> solaris.

As you should not, these are data transport QAQC for the respective
"targets".  Initiators make no money, but "targets" do.

Quote:> if you wish to discuss the various merits of parts of the iSCSI protocol,
> there are forums for that kind of thing.
> linux-kernel is not one of them.

Yep, will see you that refector to discuss a hole in the ERL=1 with a
header digest failure w/ the S_BIT set.  It get tossed out and now you end
up with a status sequuence number order problem.

Who owns the mess, Target or Initiator ?

I do not care, because I have both sides covered to support all 11:11
regardless of the support level when talking to your switch with my
initiator, or your initiator talking to my target.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. iscsi initiator needed

Hi all,

I am just starting to configure Solaris iSCSI and I wonder if there is a
software for Solaris iSCSI initiator (not CISCO)

I have in my lab several sun computers with Solaris 8 and Solaris 9 like:

     SunFire v240,SunFire v120,SunFire v210,SunFire E280r
     Enterprise 450,Enterprise 250, Blade 150.

Any help would be appreciated.

Thomas.

2. HELP: Apache on Solaris 2.6 w/ log files > 2 GB

3. FWD: PLEASE READ ALL OpenSource users!

4. Taxan Ergovision 580 PLUS LR monitor

5. Setting up Gauntlet Filtering..

6. Name Server Question

7. Fwd: Re: Fwd: Linux Kernel: down_timeout

8. Mount Error

9. Linux throws down the gauntlet to Microsoft and opens up server market

10. ISCSI support on linux?

11. Linux supported iSCSI HBAs?

12. TIS Gauntlet for Linux

13. More on Linux and iSCSI [info, not flame :)]