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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sun, 15 Jul 2012 22:03:28 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Antonio Huete Jiménez <ahuete.devel@...il.com>
Cc:	Andreas Dilger <adilger@...ger.ca>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] Add support for DragonFly BSD operating system.

On Mon, Jul 16, 2012 at 02:26:57AM +0200, Antonio Huete Jiménez wrote:
> I've pasted both new patches in this email with the intention of
> producing less traffic in the mailing list, but I'm unsure if this
> is the correct thing to do, opposed to sending one mail per patch.

It's better to send one mail per patch.  The reason for that is we
have automated tools that do the right thing with patches sent one per
e-mail.  This includes patchwork (which tracks patches sent to the
mailing list; see
http://patchwork.ozlabs.org/project/linux-ext4/list/) and "git am".

Just use the git send-email tool; it will do the right thing.

There are places where you are using #if defined(__DragonFly__) and
there are other places where you are using #ifdef DIOCGPART.  Is there
a reason for this?

In general, it's better to avoid using explicit feature tests rather
things like defined(__Dragonfly__) or defined(__solaris__).  What if
an OS changes names or forks (i.e., like Open Solaris, Nextensa,
Illumos, etc.).

And the combination of an #ifdef based on HAVE_SYS_DISKLABEL_H,
DIOCGPART, and defined(__DragonFly__) raises red flags that the
combinatorics may be very brittle in the long run.

Regards,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists