[illumos-Developer] Improved support added for Marvell Gigabit Ethernet controllers

Garrett D'Amore garrett at nexenta.com
Wed Aug 11 14:36:12 PDT 2010


I would ask that we wait before having any drastic changes to patch submission.  There are many factors to consider, and I'm not sure I believe total anarchy in the submission process is a good thing.  What works for linux may or may not work well for us.

In particular there are licensing considerations for us which linux does not have because of the copyleft nature of gpl.

Dmitry Yusupov <dmitry at nexenta.com> wrote:

>While community appreciate patch submissions, I think we need to discuss 
>the rules how patches can be submitted to our mailing lists.
>
>I suggest we will do what Linux kernel community effectively using for 
>so called "random" hacker patch submissions:
>
>http://www.linuxchix.org/content/courses/kernel_hacking/lesson9
>
>Most interesting portions of this lesson:
>
>"""
>Distributing your patch
>
>Most patches are small enough to be included in an email. While some 
>maintainers refuse to accept patches in attachments, and some refuse 
>MIME encoded attachments, all maintainers will accept a patch that is 
>included in the body of a text-only email. Make sure your mail client 
>isn't mangling your patch - if you aren't sure, email your patch to 
>yourself and apply it to make sure other people will be able to apply it 
>to. Most Linux mailing lists like patches with a meaningful 
>English-language subject, prefixed with the string [PATCH] so that it's 
>easy to find and read patches.
>
>If your patch is too big to send by email (around 20K or larger), put it 
>on a web page or ftp site where other people can download it, and put 
>the URL in your email.
>
>Political considerations
>
>If all that mattered is that your patch was well-formed, correct, and 
>fixed a bug, submitting a patch would be a lot simpler. Instead, your 
>patch needs to be tasteful, timely, interesting, and considerate of the 
>maintainer's ego. Most of the time, a simple bugfix will be immediately 
>accepted. Occasionally though, you'll run into bigger problems. The 
>important thing to remember is that you can't work around the Linux 
>maintainer system, you have to work through it. Read a few threads on 
>linux-kernel in which people tried to wheedle their patch into the 
>kernel (I've tried - and failed). If your patch isn't accepted, listen 
>to what other people are saying about it and try to fix the problems 
>with it. The most often rejected patch is the feature patch - adding a 
>new feature that is considered tasteless by the other maintainers. Don't 
>waste your time trying to get that patch accepted, just maintain it 
>separately. If enough people find the patch useful, you'll gain a 
>reputation as being a useful kernel hacker among all the people who 
>download and use your patch.
>
>Sometimes, a maintainer just can't accept a patch because of his or her 
>ego. When this happens, the only option is to maintain a better version 
>of the code independently of the main kernel. Often, externally 
>maintained code that proves to be better will replace the in-kernel code 
>after a while, which is one way to become a maintainer."""
>
>On 08/11/2010 04:41 AM, ken mays wrote:
>> Hi Garrett,
>>
>> Here is my 'diff' of changes to the yge driver here to review.
>>
>> Filed under  CR 6975987 as yge enhancement for Oracle.
>>
>> Based on ON snv_147 (hg):
>>
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/pkg/manifests/driver-network-yge.mf
>>       42 driver name=yge perms="* 0666 root sys" \
>>
>>           alias=pciex1186,4001 \
>>           alias=pciex1186,4b00 \
>>           alias=pciex11ab,4354 \
>>           alias=pciex11ab,4355 \
>>           alias=pciex11ab,4360 \
>>           alias=pciex11ab,4361 \
>>           alias=pciex11ab,4362 \
>>           alias=pciex11ab,4363 \
>>           alias=pciex11ab,4364 \
>>           alias=pciex11ab,4365 \
>>           alias=pciex11ab,4366 \
>>           alias=pciex11ab,4367 \
>>           alias=pciex11ab,4368 \
>>           alias=pciex11ab,4369 \
>>           alias=pciex11ab,436a \
>>           alias=pciex11ab,436b \
>>           alias=pciex11ab,436c \
>>           alias=pciex11ab,436d \
>>           alias=pciex11ab,4370 \
>>           alias=pciex11ab,4380 \
>>           alias=pciex11ab,4381
>>        file path=kernel/drv/$(ARCH64)/yge group=sys
>>
>>
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/yge/yge.c
>>
>>     1237 	    dev->d_hw_id>  CHIP_ID_YUKON_UL_2) {
>>     1275 		dev->d_clock = 156;	/* 156 Mhz */
>>
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/yge/yge.h
>>
>>     82 #define	DEVICEID_MRVL_4354	0X4354
>>        #define	DEVICEID_MRVL_4355	0X4355
>>        #define	DEVICEID_MRVL_4360	0x4360
>>        #define	DEVICEID_MRVL_4361	0x4361
>>        #define	DEVICEID_MRVL_4362	0x4362
>>        #define	DEVICEID_MRVL_4363	0x4363
>>        #define	DEVICEID_MRVL_4364	0x4364
>>        #define	DEVICEID_MRVL_436A	0x436A
>>        #define	DEVICEID_MRVL_436B	0x436B
>>        #define	DEVICEID_MRVL_436C	0x436C
>>        #define	DEVICEID_MRVL_436D	0x436D
>>        #define	DEVICEID_MRVL_4370	0x4370
>>        #define	DEVICEID_MRVL_4380	0x4380
>>        #define	DEVICEID_MRVL_4381	0x4381
>>
>>
>> Hopefully it is easy to make these patch changes and then run a quick test.
>>
>> ~ Ken Mays
>>
>>
>>
>>
>>
>>
>>
>> --- On Tue, 8/10/10, Garrett D'Amore<garrett at damore.org>  wrote:
>>
>>> From: Garrett D'Amore<garrett at damore.org>
>>> Subject: Re: [illumos-Developer] Improved support added for Marvell Gigabit Ethernet controllers
>>> To: "ken mays"<maybird1776 at yahoo.com>
>>> Cc: developer at lists.illumos.org
>>> Date: Tuesday, August 10, 2010, 12:14 PM
>>> This is funny, because I've been
>>> working on the same thing in parallel.
>>> I'd made some progress, but was having trouble with
>>> certain
>>> initializations -- the device would work sometime, but not
>>> always.
>>>
>>> Can I see your diffs.  As I have a very immediate need
>>> for this, I can
>>> test your code, and if it works I *will* integrate into
>>> illumos
>>> immediately.
>>>
>>>      - Garrett
>>>
>>>
>>> On Tue, 2010-08-10 at 09:01 -0700, ken mays wrote:
>>>> Hello,
>>>>
>>>> I worked on adding or improve support to the yge
>>> device driver for the
>>>> following Marvell Yukon PCI Express Ethernet
>>> controllers:
>>>>
>>>> Marvell Yukon II 88E8057
>>>> Marvell Yukon Optima 88E8059 w/ AVB
>>>> Marvell Yukon II 88E8062 dual port
>>>>
>>>> The enhancements were added to ON snv_146
>>> consolidation for possible illumos-gate inclusion.
>>>>
>>>> A bug report was also filed to Oracle for official
>>> enhancement review and support.
>>>>
>>>> ~ Ken Mays
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Developer mailing list
>>>> Developer at lists.illumos.org
>>>> http://lists.illumos.org/m/listinfo/developer
>>>
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Developer mailing list
>> Developer at lists.illumos.org
>> http://lists.illumos.org/m/listinfo/developer
>>
>>
>
>_______________________________________________
>Developer mailing list
>Developer at lists.illumos.org
>http://lists.illumos.org/m/listinfo/developer
>


More information about the Developer mailing list