--SvF6CGw9fzJC4Rcx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 21, 2006 at 02:56:33PM -0600, Eric Haszlakiewicz wrote:
> On Mon, Feb 20, 2006 at 09:46:11AM -0800, Matt Thomas wrote:
> >=20
> > On Feb 20, 2006, at 9:14 AM, Thor Lancelot Simon wrote:
> >=20
> > >What's really needed is an in-kernel loader.  At least two developers
> > >have stepped up in the past and claimed to be in the midst of writing
> > >one of those, but nothing's ever come of it.
> > >
> > >I also question whether, without versioning of modules and without
> > >inter-library dependencies, this will actually ever be particularly
> > >useful.  Finally, I think it's important to retain the ability to
> > >build a monolithic kernel for applications where the entire blob
> > >must be verified -- *without* running a chain of dependencies and
> > >hoping you got it right.
> >=20
> > The one mistake I think we have is that LKM's are special.  IMO, there
> > should be nothing special about a LKM.  It should use the exact same
> > services to make itself to the kernel as a static module built into a
> > monolithic kernel.
>=20
> 	Including config.  I actually started working on this, but it then fell
> to the same fate as those in-kernel loaders.  I have some pieces somewhat
> working if anyone else is intersted in it.  The basic idea was that
> a lot of the glue code that is currently written by hand can be generated
> by config by using a fragment of a kernel config file.

When I last worked on that, it's been a while, I changed config(1) to
merge the concepts of attributes and modules, i.e. a module is a
collection of attributes.  Ideally, a module should only be one
attribute, but some source files depend on several attributes through
the logical operators of config(1).  The module name was built from
the names of the included attributes, all of this conditioned by the
user specifying what was to be compiled as a module in the options
selection part of the configuration file.

The idea behind that was to have a GENERIC were every possible element
was modular;  the user would just have to link the pieces together to
obtain a monolithic kernel like the usual.

The config(1) changes were complete, but the rest was barely touched.
I might still have the code somewhere...

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--SvF6CGw9fzJC4Rcx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ/uND9goQloHrPnoAQLozQf+La8KBBG71fQDq1SQKqBrl18oFh5bBnF7
p/ETiPTqP6RAA329IxOHqlf8r7R34bkYg1lXH4a/6fozzYt7bheGoexa2NfPpVgC
O/uT+3yYgIJV2jfdHtFZH4xmEwKdqugj0WITqOjtcAqLwPp5j9YT0ayaBZbVpTsM
IdmgpK9LvF+Dgrkb84CROo75P1LgxW5nPQoyIdDlpVQOIZ6+cpt/3LG5hqs7jstu
w+44Jn9wdQKRIdMV2tooZPOfZhpbie5YJby1cIuXWcWbl5NPZv+EYWvzKMTn2Pqr
qo+OkjIQgnGQ9Lr+a/jtlrbMN2cPR3C4/bMM0Xwkg2ULhwau/BcmVw==
=sl6r
-----END PGP SIGNATURE-----

--SvF6CGw9fzJC4Rcx--