On 23.04.2018 10:13, Sascha Hauer wrote: > On Sun, Apr 22, 2018 at 10:27:11AM +0200, Oleksij Rempel wrote: >> Hi Gerd, >> >> please use scripts/checkpatch.pl >> >> currently i get >> total: 2020 errors, 0 warnings, 2020 lines checked >> >> We use kernel coding style. Please read it: >> https://www.kernel.org/doc/html/v4.16/process/coding-style.html >> >> Am 20.04.2018 um 10:01 schrieb Gerd Pauli: >>> Adds ccryptlib library in crypto which implements a >>> stream cipher based on the block cipher Rijndael, >>> the candidate for the AES standard. >>> Compatible with the ccrypt tool in linux >>> from Peter Selinger. >>> >>> Usage: ccrypt [-e|-d] -k KEYNAME_IN_KEYSTORE SRC DST >>> >>> Signed-off-by: Gerd Pauli <gp@xxxxxxxxxxxxxxxxxx> >>> --- >>> commands/Kconfig | 17 + >>> commands/Makefile | 1 + >>> commands/ccrypt.c | 249 +++++++++ >>> crypto/Kconfig | 7 + >>> crypto/Makefile | 1 + >>> crypto/ccryptlib.c | 1467 +++++++++++++++++++++++++++++++++++++++++++++++++++ >>> include/ccryptlib.h | 102 ++++ >>> 7 files changed, 1844 insertions(+) >>> create mode 100644 commands/ccrypt.c >>> create mode 100644 crypto/ccryptlib.c >>> create mode 100644 include/ccryptlib.h >>> >>> diff --git a/commands/Kconfig b/commands/Kconfig >>> index 951a86963..b6911246a 100644 >>> --- a/commands/Kconfig >>> +++ b/commands/Kconfig >>> @@ -2137,6 +2137,23 @@ config CMD_SEED >>> help >>> Seed the pseudo random number generator (PRNG) >>> >>> +config CMD_CCRYPT >>> + tristate >>> + prompt "ccrypt" >>> + select CRYPTO_CCRYPTLIB >>> + select CRYPTO_KEYSTORE >>> + help >>> + encrypting/decrypting a character stream >>> + ccrypt implements a stream cipher based on the block cipher >>> + Rijndael. >> >>> + Usage: ccrypt [-ed] [-K name] srcfile dstfile >>> + >>> + Options: >>> + -e encrypt srcfile to dstfile >>> + -d decrypt srcfile to dstfile >>> + -k name use key with name from keystore >>> + >> >> usage help should be provided by the command, not within Kconfig > > Indeed we have the help provided in the Kconfig text for all commands > that were present at that change. I don't really think it's worth > continuing this though. > >>> + * This program is free software; you can redistribute it and/or >>> + * modify it under the terms of the GNU General Public License as >>> + * published by the Free Software Foundation; either version 2 of >>> + * the License, or (at your option) any later version. >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> + * GNU General Public License for more details. >>> + */ >>> + >>> +/* ccrypt implements a stream cipher based on the block cipher >>> + Rijndael */ >>> + >>> +/* needs library ccryptlib and keystore from barebox */ >> >> no need for this comment, needed headers are already included >> >>> +#include <common.h> >>> +#include <command.h> >>> +#include <libfile.h> >>> +#include <getopt.h> >>> +#include <fcntl.h> >>> +#include <fs.h> >>> +#include <ccryptlib.h> >> >> i prefer headers sorted alphabetically. this helps to reduce >> patch conflicts. > > And I prefer the reverse christmas tree ordering ;) > > To be honest, I don't care about the ordering at all, but at least as > long as we haven't agreed on some ordering and written it down somewhere > we shouldn't enforce any ordering for patch submitters. ok. by applying old patches, i made experience that "append as last in the list" will mostly end as patch conflict in comparison to "add in alphabetically ordered list". May it is worth to start this practice.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
