Date: Thu, 05 Feb 2004 07:45:49 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: phk@phk.freebsd.dk Cc: arch@freebsd.org Subject: Re: Resolving the crypto duplicity... Message-ID: <20040205.074549.128866887.imp@bsdimp.com> In-Reply-To: <38921.1075966216@critter.freebsd.dk> References: <200402042324.18434.sam@errno.com> <38921.1075966216@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <38921.1075966216@critter.freebsd.dk>
"Poul-Henning Kamp" <phk@phk.freebsd.dk> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040205.074549.128866887.imp>