lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 21 Mar 2018 12:46:17 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     rao.shoaib@...cle.com
Cc:     netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: Few questions about submitting patches

From: Rao Shoaib <rao.shoaib@...cle.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ