I would like to summary all these issues brought up so far.
First is whether it's legal to rewrite linux kernel to make it a solaris
application. The answer is yes.
Because user level application will not affect solaris kernel, per
gplv2. This is same as
all this gpl'ed application we are using now, such as gnome. This has be
confirmed by
our lawyer.
Second, technique issue. After all these discussion, I reach the
conclusion that what is lacked
of is not nic drivers, but the approach to find the driver that can
drive a specific hardware.
Then I put my investigation result into my blog. Hopefully, when
google's robot reaches it,
many people can use it.
Anyway, I would like to clarify several of my idea for it is still
possible to apply it to other areas.
As for the performance issue, sure, it will be much slower than kernel
driver. My primary
test shows that the interrupt handling speed is about 6-7 times slower.
It is far from acceptable
for the application where extreme performance critical, but it is
acceptable for most of
daily work.
I feel it could be useful for writing driver for some customized
hardware since development
and debug in user mode is much more convenient than in kernel mode.
Thank you
--Freeman
James Carlson wrote:
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Hi Freeman,
How does UMD allow you to "leverage linux nic driver source codes
without any legal issues"?
It is very possible to cause license issue if I ready some linux driver
code and then
write a solaris kernel driver. But if I implement the solaris driver in
user mode,
it will not compromise solaris kernel.
This sounds a bit wobbly to me.
The issue with porting over Linux drivers to the Solaris kernel is a
Sun problem and perhaps an ON and OpenSolaris problem, but it's not a
general problem.
In other words, we have the rule for ON because of the lack of clarity
in the GPLv2 regarding what is considered a "mere aggregation" and
what constitutes a dependency that invokes the GPL viral provisions.
Nobody really knows, even with a clearly delineated DDI, so it's a
risk not worth taking. (There are some who think that kernel modules
are distinct enough not to cause a problem, but the issue lacks
clarity.)
Others -- those not contributing directly to ON via OpenSolaris -- can
and do have other considerations. I'm not a lawyer (and thus you
should _not_ rely on my advice), but I see no obvious problem for any
third party to port a GPLv2 kernel driver and post it to
sourceforge.net or similar site for others to download and use on
their own Solaris system.
Thus, I'm not sure what problem you're actually solving for
OpenSolaris itself. Do you really want to bundle Linux drivers in
user space with Solaris itself? If so, then I object because it's a
hack -- if it's possible at all (Linux lacks a DDI), it'll very likely
perform badly and give Solaris a worse name as a result.
If you don't want to bundle the Linux drivers with Solaris, then
where's the problem being solved? The barriers imagined don't seem to
exist, as best I can tell.
More details. It is very possible that the user mode part will follow GPL,
for it may be copied from GPL'ed code, but according to the clause of GPL,
this does not require the kernel part to follow gpl.
I don't see that this actually fixes any existing problem, and it
clearly causes new ones -- including a likely impossible support task.
(Consider the narrow range of supported Linux variants for BrandZ; and
that was with the relatively stable user space APIs rather than the
free-for-all in the Linux kernel.)
So, -1 from me. I don't see a point.
_______________________________________________
networking-discuss mailing list
[email protected]
