linux-kernel - Re: [ANNOUNCE] Merkey's Kernel Debugger

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]

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/