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

On Tue, Nov 22, 2005 at 08:34:55PM -0800, Jason Thorpe wrote:
>=20
> On Nov 22, 2005, at 3:13 PM, Andrey Petrov wrote:
>=20
> >It could be done by kernel linker(loader) so he'll be responsible =20
> >for module loading
> >and initialization, and so it wouldn't be needed to code =20
> >dependiencies explicitly.
>=20
> Hmm... For things that would be loaded at run-time, that would work =20
> great... but not so well for things statically compiled into the =20
> kernel.  Though, a string-based dependency list for those things =20
> statically compiled in could be made to work, too.

It would be nice to pre-sort the list, say during kernel build. Since the=
=20
built-in ordering won't change from boot to boot, it will be a little=20
easier. We then only need the kernel to contain a routine to walk the=20
list and init in order; we won't need to embed the dependency-graph=20
builder in the kernel.

Also, for built-in, I think it would be best to avoid coding the
dependencies (the alternative I see to ordering). By "coding" I mean
something where a module has a "make sure X is loaded" call or calls at
its beginning. My concern is that with some dependnecy orders, we can end
up gobbling up a lot of kernel stack and blow it, whereas with another
order order the exact same modules load with little stack.

Say A depends on B, which depends on C, which depends on D, which depends=
=20
on E. If we init E, D, C, B, and A in that order, we only need one=20
routine's worth of stack at a time. If however we init'd A first, its=20
dependency verification would trigger B's init, which would trigger C's,=20
which would trigger D's, and then finally E's. So we have all five=20
routine's worth of stack active at once.

Maybe we could bash rc.order to handle this during kernel build??

Take care,

Bill

--DocE+STaALJfprDB
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDhPJgWz+3JHUci9cRAq/aAJ9KtaGOXIzb/ZSjg0CimprYUxfKCACfZy0G
LRL6+BbtZWyn5jkWHS8NA2Y=
=Xwm4
-----END PGP SIGNATURE-----

--DocE+STaALJfprDB--