From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=GwPQ=KB=saout.de=dm-crypt-bounces@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,
	USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id D0536C433ED
	for <dm-crypt@archiver.kernel.org>; Thu,  6 May 2021 14:52:34 +0000 (UTC)
Received: from mail.server123.net (mail.server123.net [78.46.64.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id 44E7261166
	for <dm-crypt@archiver.kernel.org>; Thu,  6 May 2021 14:52:34 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44E7261166
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dm-crypt-bounces@saout.de
X-Virus-Scanned: amavisd-new at saout.de
Authentication-Results: mail.server123.net (amavisd-new);
	dkim=pass (2048-bit key) header.d=gmail.com
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::333; helo=mail-wm1-x333.google.com; envelope-from=gmazyland@gmail.com; receiver=<UNKNOWN> 
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.server123.net (Postfix) with ESMTPS
	for <dm-crypt@saout.de>; Thu,  6 May 2021 16:49:34 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id 4-20020a05600c26c4b0290146e1feccd8so3201570wmv.1
        for <dm-crypt@saout.de>; Thu, 06 May 2021 07:49:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=from:subject:to:references:message-id:date:user-agent:mime-version
         :in-reply-to:content-language:content-transfer-encoding;
        bh=LJlu0VBm4xe8fjgk5jfw3rjrJl/2iQfg8hkeSA1nPbo=;
        b=D6aXsK/eK7CzxEQy7RvG3VIxKpvXG005eZHqjv3c4QRtKxLaimvSPIiMVBhWrOrMvs
         OOw33LcahXxTlLYI6GOPskIWt12SyF0l3QsRNIIUFGTjwF7yr5Y6jfJDimFt/25F09Jl
         zK9SaR3Hohhi5XBsYPz2I9wGD1+/9IFljEp+bkF+8xQST/cRZivdYV42cruPC26EXyoa
         /lqCvVaELh9tjcqaCI+1hNMBRQDaPu8OIHy8yjHRUpk0Z9ix3GoAgNuljkzsE5hFWTVi
         K09XAbUAzRhKB7t//vQnVTELG6wEPlSi+BYm9kFCAKTc1kZIxFEVaBDuOIfZKY53vZWY
         fR+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:from:subject:to:references:message-id:date
         :user-agent:mime-version:in-reply-to:content-language
         :content-transfer-encoding;
        bh=LJlu0VBm4xe8fjgk5jfw3rjrJl/2iQfg8hkeSA1nPbo=;
        b=PRH5RIRTtToGir7KHCGFqwA3BYjpNcQu21T+ULhSlNu8iIRSWhlstNjZjRLE445PkH
         NUi/N68fzpt8b4a39vAhCBfooCK9Ka4YVsqYZSVr8HwJpldyyP2dt0WJJ0hEjZVNLvYU
         dabV0z8CyXTJl9sIGGEHQEayA3smsR2O9Hd/dlvCGwwfY7yqxQC5NupELRl2cHGtleXj
         2YyqKfRTfuoTGqmgkwDnbvXvkmDmPuJapL+Tx3kPfUxp+1ERER4a21Q14zU3ILQ4kR5A
         ssYYaV6cxpxG5xr65OXxo0xbXljcR2PF5Ykvid/FMNj7qW1ZPRUa9h4Yni2VOBTF/SXM
         ihxQ==
X-Gm-Message-State: AOAM533REI1mrNleZujuYDaQU5d//33ofCpzTyheA/IwmmurOdR178bo
	n3acgqT/NqrK/jmcPznNVndngZplzFM=
X-Google-Smtp-Source: ABdhPJydVvjyjjusAaB0xMJVAOCO5yAqLZEbJIKpM60wjIjFdH1G4O235HQ7mCCGT3W1IKNv1AAP9Q==
X-Received: by 2002:a1c:20c4:: with SMTP id g187mr4464806wmg.97.1620312573771;
        Thu, 06 May 2021 07:49:33 -0700 (PDT)
Received: from [192.168.2.27] (39.35.broadband4.iol.cz. [85.71.35.39])
        by smtp.gmail.com with ESMTPSA id v18sm5565920wro.18.2021.05.06.07.49.31
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 06 May 2021 07:49:32 -0700 (PDT)
From: Milan Broz <gmazyland@gmail.com>
To: "Schneider, Robert" <robert.schneider03@sap.com>,
 "dm-crypt@saout.de" <dm-crypt@saout.de>
References: <AM0PR02MB558518FD785237C3B2D0A7618F589@AM0PR02MB5585.eurprd02.prod.outlook.com>
Message-ID: <bb720c2f-e93d-90ba-3a9a-d76a13f30614@gmail.com>
Date: Thu, 6 May 2021 16:49:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <AM0PR02MB558518FD785237C3B2D0A7618F589@AM0PR02MB5585.eurprd02.prod.outlook.com>
Content-Language: en-US
Message-ID-Hash: N36OT4IX6Q6VLCSQOHYL3DAEHYQ6Q6TT
X-Message-ID-Hash: N36OT4IX6Q6VLCSQOHYL3DAEHYQ6Q6TT
X-MailFrom: gmazyland@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dm-crypt.saout.de-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header
X-Mailman-Version: 3.3.2
Precedence: list
Subject: [dm-crypt] Re: Coding/style guidelines for cryptsetup?
List-Id: <dm-crypt.saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Post: <mailto:dm-crypt@saout.de>
List-Subscribe: <mailto:dm-crypt-join@saout.de>
List-Unsubscribe: <mailto:dm-crypt-leave@saout.de>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

On 06/05/2021 13:19, Schneider, Robert wrote:
> Hi,
> 
> What are the coding and style guidelines when you want to propose a patch to cryptsetup?

Code style is very similar to Linux kernel code style.

I will add some doc later (also with "how to contribute docs") etc.

> 
> I don't quite get a clear picture from the source code for some things, and I couldn't find documentation on it inside the repo.
> I can write a clang-format ruleset if I know the rules...

If a formatting exception is more readable, then just format the code differently.

IMO source code is for people, not for machines enforcing rulesets.
(This ends with dealing with patches reshuffling spaces only, we do not need that.)

Anyway, if you plan to write something more sophisticated, better report issue
and discuss it first, please.

Some notes below, but these are not set in stone.

> Here are some things I've noticed while reading the source code, and some remaining questions:
> 
> - mostly restricted to C90, e.g. variable declarations at top of functions; but there some use of C99 features like designators in array initializations
>   -> do we have to declare variables at the top of functions?

yes

>   -> are // style comments allowed?

Just for temporary comments (like TODO etc). Definitely prefer C /**/ comments.

> - would adding -pedantic in GCC be acceptable? (not sure how that would work in autotools)

Not for now. I use many extra warnings for tests, but pedantic is producing really garbage sometimes.
Better spent time with running static analyzers (scan-build, coverity, LGTM, ...)

Both gcc a clang compilation should be clean.

> - tabs are used for indentation

yes, tabs everywhere, even in test scripts.

> - unclear if spaces for alignment are OK
>   -> tab == 8 spaces?

as kernel - default is 8

> - how to indent when wrapping lines, e.g. for function parameters? 2 tabs? Align at ( with spaces?
>   -> sometimes, function declarations put every parameter on its own line

This is not strict, just keep it readable (same as other in the same file).
This (and comments) is the only part where tabs and spaces are mixed.
Definitely it is not unified now.

> - top-level declarations like functions and structs have { on new line, if/loops/etc inside functions have { on same line, else on same line as }, if/else without braces is allowed
> - one space between if/while/for/.. and the (> - documentation of API via doxygen (@ style, not \ style)
> - internal documentation via plain comments, no text on first line and all lines starting with aligned *

All above - yes, very similar to kernel codestyle.

> - max line length?

Lively discussion on this topic is in progress :-)

I would say: if the code is readable, prefer old-school 80 chars.
If longer line helps, no problem but try to exceed 100-110 chars.

Do not reformat embedded foreign code (currently mainly Argon2 crypto lib).

> - the * for pointers binds to the variable name (void *p instead of void* p)
> - multiple declarations in the same statement are allowed

yes

> - functions with external linkage have a prefix like LUKS2_

LUKS2 is internal prefix (for sub-format dirs, similar to LUKS/TCRYPT,VERITY, ...),

Libcryptsetup uses  crypt_* prefix for exported objects.

> - types are not typedef'ed -> struct crypt_device instead of crypt_device_t

not everywhere, something was based on API evolution and it makes no sense to change
it just for the typedef cleanups.

> - there are file comments with copyright notices
>   -> how to create a new file?

Copyright note should always mention authors of that file.
(Otherwise it no longer makes much sense, but we keep that for tracking authors.)

I try to license new code with LGPL 2.1 or any later, but most of code is still GPL2 or any later.
(Cannot fix it globally, there was not agreement of former authors to switch to LGPL.)

Adding file - just copy header with proper license (GPL or LGPL only as above) and copyright.
There are some internal headers with function prototypes, use these.

But why do you need to add source code files?

Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de