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] [thread-next>] [day] [month] [year] [list]
Message-ID: <4897070E.5050509@s5r6.in-berlin.de>
Date:	Mon, 04 Aug 2008 15:41:34 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	jmerkey@...fmountaingroup.com
CC:	Josh Boyer <jwboyer@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Merkey's Kernel Debugger

jmerkey@...fmountaingroup.com wrote:
>> On Sun, 2008-08-03 at 13:36 -0600, jmerkey@...fmountaingroup.com wrote:
>>>
>>> This patch is formally submitted for consideration for inclusion in the
>>> base linux kernel.
>>>
>>> ftp://ftp.wolfmountaingroup.org/pub/mdb/mdb-2.6.26-ia32-08-02-08.patch
>>
>> Formally submitted patches should be sent to the list inline.  Reviewing
>> something on an FTP server just becomes that much harder.
>>
>> josh
>>
>>
> 
> Submitted as inline patches.

Some non-technical comments to the patch series:
  - Each patch posting in a patch series should have an own Subject and
    changelog which specifically describes the included patch.
  - The Developer's Certificate of Origin is written simply as a single
    line:
    Signed-off-by: Jeffrey Vernon Merkey <email@...ress>
    This line needs to be included in the changelog of each patch, i.e.
    precedes the diff.  (Tools which harvest patches from mboxes are
    trained to pick the changelog up from before the diff.)
  - The MUA rewrapped some lines.
  - File name and date of last change are redundant information and are
    better left out of the source files.
  - Understandably for a port from other kernels, there are clashes with
    Linux kernel's coding style like CamelCase names, comment style,
    indentations.
  - Why define LONGLONG, WORD, BYTE and so on?  They could be plain
    unsigned char etc., or u8 etc. if you like it brief.
  - Boolean values should be the standard true and false, not locally
    defined TRUE and FALSE.
  - Usually the #include's are not collected in an intermediary header
    (as in patch 7/25) but put directly into the files which require
    a particular #include.

I haven't looked in detail at the patches; it's far out of my area of
experience...
-- 
Stefan Richter
-=====-==--- =--- --=--
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ