From owner-freebsd-arch@FreeBSD.ORG Thu Feb 5 06:46:07 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5D8416A4CE for ; Thu, 5 Feb 2004 06:46:07 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1680543D1F for ; Thu, 5 Feb 2004 06:46:05 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i15Ek0nJ026353; Thu, 5 Feb 2004 07:46:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 05 Feb 2004 07:45:49 -0700 (MST) Message-Id: <20040205.074549.128866887.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <38921.1075966216@critter.freebsd.dk> References: <200402042324.18434.sam@errno.com> <38921.1075966216@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sam@errno.com cc: arch@freebsd.org Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 14:46:07 -0000 In message: <38921.1075966216@critter.freebsd.dk> "Poul-Henning Kamp" writes: : But as I said, it may be time to discuss the overall issue of kld : dependencies, rather than just scratch my own little itch... Typically people just put the module dependency into their kld and get on with their lives. There's really little to discuss except maybe making an opencrypto module... At least as far as the dependency issue with klds. I have no comment on the code duplication aspects. I've been using something similar to share code between a couple of different drivers I work on. There's a few other drivers in the tree that depend on various things (wlan, elink, md5, etc). The md5 depend could easily be a more generic crypto depend. It was convenient at the time to do what I did. If there's any kind of kld issues, it is that the core part of the kernel is too large and needs to be a little more modular. However, breaking things down further than they are can be hard. The problem as I see it is that there are too many 10k-100k chunks that are non-optional. This makes it hard to subset below a certain point. Warner