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

Dmitry Yusupov dmitry at nexenta.com
Wed Aug 11 11:12:56 PDT 2010


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
>
>



More information about the Developer mailing list