Subject: Re: [RFC][PATCH] Make cryptoapi non-optional?
From: Robert Love <rml@tech9.net>
To: "David S. Miller" <davem@redhat.com>
Cc: Matt Mackall <mpm@selenic.com>, linux-kernel@vger.kernel.org,
       akpm@osdl.org, jmorris@intercode.com.au
In-Reply-To: <20030809204927.46b84c83.davem@redhat.com>
References: <20030809074459.GQ31810@waste.org>
	 <20030809143314.GT31810@waste.org> <1060481247.31499.62.camel@localhost>
	 <20030810031418.GW31810@waste.org>
	 <20030809204927.46b84c83.davem@redhat.com>
Content-Type: text/plain
Message-Id: <1060488099.31499.66.camel@localhost>
Mime-Version: 1.0
Date: Sat, 09 Aug 2003 21:01:39 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 780
Lines: 21

On Sat, 2003-08-09 at 20:49, David S. Miller wrote:

> I definitely agree, removing the integrity of random.c is not
> an option.  Even things inside the kernel itself rely upon
> get_random_bytes() for anti-DoS measures.

OK, fair enough.  I liked the idea because it let things stay optional,
but also gave us no excuse not to merge Matt's changes.

I would have no problem requiring cryptoapi, but what if it increases in
size?  Requiring a large (and definitely oft-used for many people)
feature isn't size, either.

	Robert Love


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/