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: <Pine.LNX.4.61.0608311607441.5900@yvahk01.tjqt.qr>
Date:	Thu, 31 Aug 2006 16:16:46 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Steven Whitehouse <swhiteho@...hat.com>
cc:	linux-kernel@...r.kernel.org,
	Russell Cattelan <cattelan@...hat.com>,
	David Teigland <teigland@...hat.com>,
	Ingo Molnar <mingo@...e.hu>, hch@...radead.org
Subject: Re: [PATCH 01/16] GFS2: Core header files

>+ *
>+ * This copyrighted material is made available to anyone wishing to use,
>+ * modify, copy, or redistribute it subject to the terms and conditions
>+ * of the GNU General Public License v.2.
>+ */

"v2" perhaps? From a math pov, the extra dot implies v0.2.

>+struct gfs2_log_operations;

I would suggest listing only struct lines that are actually required, i.e. the
compiler would barf without them.

>+enum {
>+	/* Actions */
>+	HIF_MUTEX		= 0,
>+	HIF_PROMOTE		= 1,
>+	HIF_DEMOTE		= 2,
>+	HIF_GREEDY		= 3,

I leave it to you whether going with the above or

enum {
   HIF_MUTEX = 0,
   HIF_PROMOTE,
   HIF_DEMOTE,
   HIF_GREEDY,
   ...
};

If these values need to stay the same, for example to maintain on-disk
compatibility, I prefer the former, though.

>+	/* Quota stuff */
>+
>+	struct gfs2_quota_data *al_qd[4];

What four quotas can there be? Use the MAXQUOTAS macro if feasible.

>+struct gfs2_quota_lvb {
>+        uint32_t qb_magic;
>+        uint32_t __pad;
>+        uint64_t qb_limit;      /* Hard limit of # blocks to alloc */
>+        uint64_t qb_warn;       /* Warn user when alloc is above this # */
>+        int64_t qb_value;       /* Current # blocks allocated */
>+};

Is this an on-disk structure or why is there a __pad field?



Jan Engelhardt
-- 
-
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