答复: [korg]help: How to submit a kernel driver on kernel.org.

[Ilija Hadzic]

A couple of non-technical things. First, I think you are sending the patch 
to the wrong list. dri-devel is for drivers that go under drivers/gpu/drm. 
Your driver is apparently fbdev driver and thus belongs to 
linux-fbdev at vger.kernel.org list (see the Maintainers file)

Second, your patch generates about 9000 coding style errors when you run 
through ./scripts/checkpatch.pl script available in the Linux kernel tree. 
You need to clean up. See also Documentation/CodingStyle. Also, you must 
break up the patch into smaller self-contained units that logically make 
sense. Nobody can review 17000 lines of code in one shot.

Last, but probably the most important. All your files have the proprietary 
license in the comment overhead. You (actually your company lawyers) have 
to decide which license you are releasing this dirver under and make sure 
it is compatible with Linux kernel (i.e. GPL) and you have to state that 
in each file that is being added.

-- Ilija


On Fri, 9 Mar 2012, [utf-8] Aaron.Chen  é~Y~Hä¿~Jæ~]° wrote:

> Hi Paul&Alex,
>
> Thank you very much for your great help.
>
> Here is the first patch.
>
> Regards
> Aaron
>
> -----邮件原件-----
> 发件人: Paul Menzel [mailto:paulepanter at users.sourceforge.net]
> 发送时间: 2012年3月6日 22:38
> 收件人: Alex Deucher
> 抄送: Aaron.Chen 陈俊杰; caesar.qiu 裘赛海; dri-devel at lists.freedesktop.org
> 主题: Re: [korg]help: How to submit a kernel driver on kernel.org.
>
> Dear Aaron,
>
>
> Am Dienstag, den 06.03.2012, 08:47 -0500 schrieb Alex Deucher:
>> On Mon, Mar 5, 2012 at 11:13 PM, Aaron.Chen  陈俊杰 wrote:
>
>>> Thank you very much for your guide. It's a great help for me.
>>>
>>> But I still have a little problem with the patch thing. I'm not familiar with the git.
>>> 1.Shall I need to do the clone and get the source location and target directory first?
>>> 2.Where is the source location and target directory?
>>> 3.Our driver has pass the customer's test from kernel version 2.6.5 to 3.0.0, So what shall I do to submit a driver cover all these kernel version.
>
> you can only get new features included upstream in the latest Linux kernel. So earliest version would be 3.4. You have to maintain you own repository for earlier version. But backporting should be not so much trouble if you have it included upstream.
>
>>> 4.or just email you the source code and tell you the changes?
>>>
>>> I'm looking forward your re-guide. Thank you so much.
>>
>> Your best bet it to clone Linus' git tree and then apply your patches:
>>
>> 1. clone Linus' git tree:
>>     git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> you can do this in between.
>
>        cd linux
>        git config --global user.name "陈俊杰 (Aaron Chen)"
>        git config --global user.email aaron.chen at siliconmotion.com
>
>> 2.    a) apply your first patch
>>        b)  if you patch adds new files to the source tree, add them:
>>             git add path/to/files/file.c
>>             git add path/to/files/file.h
>>             etc.  if the patch only modifies patches that are already
>> in the tree, you do not need to add them.
>>        c) when the patch is applied commit it:
>>            git commit -a -s
>>        d) when you run the commit command you will be prompted to
>> enter a commit message.  The commit message has the following format:
>>
>> subsystem: patch description
>>
>> description of what the patch does.
>>
>> Signed-off-by: Your name <your_email at domain.com>
>>
>> E.g.,
>>
>> fb: add initial code for video 5000 graphics
>>
>> This adds the initial support for the video 5000 graphics adapter.  It
>> supports vga and lcd connectors.
>>
>> Signed-off-by: Joe Developer <joe.developer at example.com>
>>
>>     e) repeat steps a-d for all of your patches 3. generate patches:
>> git format-patch -n
>>
>> where n is the number of patches you committed.  E.g., if your driver
>> consists of 5 patches:
>> git format-patch -5
>>
>> 4. Send the patches to the list.
>
> Aaron, Git is nowadays documented pretty well. So just use
>
>    git help command
>
> (like `git help commit`) to read the manual. Additionally you can just search for it using your favorite search engine. Interesting reads should be [1][2][3].
>
>
> Thanks,
>
> Paul
>
>
> [1] http://schacon.github.com/git/user-manual.html#cleaning-up-history
> [2] http://git-scm.com/documentation
> [3] http://progit.org/book/
>