10:01 a.m.
There has been some misunderstanding on what an RFC patch is and what
standards it needs to meet. Following is the official response of David
Miller.
Based on those guidelines the RFC patch we submitted meets and exceeds
the requirements. So please review it. Replacement of function pointers
will be addressed later as a separate issue.
In case there are other procedural issues that would prohibit technical
discussion please site the written rules or first ask David Miller.
There are a lot of technical issues to discuss, so if possible lets not
get tied up on process and bureaucracy. Looking forward to detailed
technical comments.
Shoaib
-------- Forwarded Message --------
Subject: Re: Few questions about submitting patches
Date: Wed, 21 Mar 2018 12:46:17 -0400 (EDT)
From: David Miller <davem(a)davemloft.net>
To: rao.shoaib(a)oracle.com
CC: netdev(a)vger.kernel.org, eric.dumazet(a)gmail.com
From: Rao Shoaib <rao.shoaib(a)oracle.com>
Date: Wed, 21 Mar 2018 09:41:13 -0700
I am new to Linux. I would like to understand the rules and
etiquettes
of engaging with the community. I have read the materials that I could
find. As I work with Linux I come across situations for which I can
not seem to find any answers. Hopefully folks on the list can answer
them.
* Submitting an RFC Patch
As I understand, an RFC patch is submitted to solicit comments and is
not for inclusion. Is it sufficient for an RFC patch to have the
correct coding style and compile, or does it need more? For example,
If the patch consists of a series of patches, does each patch have to
compile independently etc etc.
It should build and function, unless you explicitly state that the
patch is not build nor functionally tested and is intended to show
the design of the change.
* #ifdef FOO
In a regular patch consisting of a series of patches, can the above
#ifdef be used in a patch before the patch that allows the selection
of FOO. That patch is part of the series but comes later.
It is better to introduce them at the same time.
But if it is prohibitively difficult to do so, yet at the same
time properly split up your changes into manageable pieces, it
can be OK.
It is definitely determined on a case by case basis.