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

On Thu, Nov 24, 2005 at 12:41:59AM +0100, Martin Husemann wrote:
> On Wed, Nov 23, 2005 at 02:51:12PM -0800, Bill Studenmund wrote:
> > 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.
>=20
> I like the coded-dependency/init-at-first-use aproach. It also sounds
> easy to implement without major changes in our tree, on a subsystem-
> by-subsytem basis.
>=20
> I don't think the kernel stack and unpredictable initialization call
> stacks will be a big problem, since most initializations will happen
> early at certain events

How does that matter?

The problem I was discussing was that A can trigger B can trigger C can
trigger D. The only ways to prevent that are to: 1) not let dependency
chains get that big, 2) manually call inits on some often-needed systems,=
=20
or 3) sort them.

The problem is we have from 8k to 16k of stack. That should be more than=20
enough for one routine, and probably two. But if we nest a few routines=20
and we already had a few routines in progress, we can run out.

Sure, we aren't going to do this when we are in the bottom of some deep=20
call path. But we can still smash the stack to bits.

>  - during outconfig (network driver attaches -> networking is initialized)
>  - during certain syscalls (mount_msdos initializes msdos file system)
>=20
> and it can be pushed even further - like having IPv6 in the kernel but
> not initializing it untill the first IPv6 route is added (or interface
> address assigned; which then would, of course, cause link local addresses
> to pop up on all interfaces). I'm not sure we want to go there, but
> the flexibility sounds like a good think to have.

I like the on-demand aspect of the above. I just don't think that gets us=
=20
out of the way of worrying about nesting initialization.

Take care,

Bill

--5I6of5zJg18YgZEa
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDhTmvWz+3JHUci9cRAv02AJsHC4HZdBqd8z34A8nvj4U8dbbPWgCdGNeK
k1Y4rzVxIrV0qWPq4GgT/2Q=
=A8hw
-----END PGP SIGNATURE-----

--5I6of5zJg18YgZEa--