Andre Hedrick wrote:
>
> 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.
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
"[email protected]") on December 17, 1995 where he
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.helsinki.fi
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/
On Sat, 4 Jan 2003, Andrew Morton wrote:
> Andre Hedrick wrote:
> >
> > 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
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sat, Jan 04, 2003 at 06:47:43PM -0800, Andrew Morton wrote:
> Andre Hedrick wrote:
> >
> > 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.."
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.
On Sun, 5 Jan 2003, Oliver Xymoron wrote:
> On Sat, Jan 04, 2003 at 06:47:43PM -0800, Andrew Morton wrote:
> > Andre Hedrick wrote:
> > >
> > > 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.
> 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.
> 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/
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/
On Sun, 5 Jan 2003, Richard Stallman wrote:
> 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.
On Sun, Jan 05, 2003 at 07:38:15PM -0800, Andre Hedrick wrote:
> On Sun, 5 Jan 2003, Oliver Xymoron wrote:
>
> > On Sat, Jan 04, 2003 at 06:47:43PM -0800, Andrew Morton wrote:
> > > Andre Hedrick wrote:
> > > >
> > > > 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.
> 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.
> 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.."
It's a common large-vendor tactic to create bizzarre specs, and the IETF
gets sidetracked that way very easily (I'm not blaming Cisco or anyone in
particular, I am too busy at IETFs to track the politics in iSCSI).
Andre's showing some of the difficulty of implementing any IETF spec; they
are very incomplete. You can't write an IP stack purely from the spec and
get anywhere.
Also, in the case of something like iSCSI, you get two kinds of early
implementations; experimental (in this case Cisco) and production (Andre,
and presumably Microsoft). Often the quality of the experimental
implementations is awful, but nevertheless they become the reference. The
community has recently been able to produce production quality code faster
than the experimenters (anyone remember the first Halloween memo talking
about how long it would take to implement WebDAV? There was a complete,
production opensource implementation available three days after the release
of the memo, about a year ahead of MS). Looks like Andre's done that with
iSCSI.
Andrew
--On Sunday, January 05, 2003 19:38:15 -0800 Andre Hedrick
<[email protected]> wrote:
> On Sun, 5 Jan 2003, Oliver Xymoron wrote:
>
>> On Sat, Jan 04, 2003 at 06:47:43PM -0800, Andrew Morton wrote:
>> > Andre Hedrick wrote:
>> > >
>> > > 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.
>
>> 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.
>
>> 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
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Can you admit the follow, that GPL has everything to control
redistribution, and has ZERO context for copyright.
It is not clear what those words mean, so I won't agree or disagree.
The holders of the
copyright control the issues.
That is certainly true. The copyright holders of the code can permit
whatever they wish to permit, for that code. The copyright holders of
Linux can permit whatever they wish to permit, for Linux. I've said
this many times. The last occasion was in the message that you just
responded to:
> The Linux developers can certainly do this, if the copyright holders
> of the substantial functions in question go along with it.
When I say X and you respond by demanding angrily that I agree to X, I
have to think we're failing to communicate.