Date: Mon, 10 Jan 2005 14:33:58 -0700 From: Scott Long <scottl@freebsd.org> To: "Simon L. Nielsen" <simon@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/netgraph ng_base.c src/sys/sys kernel.h Message-ID: <41E2F4C6.1010000@freebsd.org> In-Reply-To: <20050110205654.GF777@zaphod.nitro.dk> References: <200501061745.j06Hj344034786@repoman.freebsd.org> <20050110184139.GE19624@funkthat.com> <20050110202344.GC777@zaphod.nitro.dk> <41E2E561.9000504@freebsd.org> <20050110205654.GF777@zaphod.nitro.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Simon L. Nielsen wrote: > On 2005.01.10 13:28:17 -0700, Scott Long wrote: > >>Simon L. Nielsen wrote: >> >> >>>On 2005.01.10 10:41:39 -0800, John-Mark Gurney wrote: >>> >>> >>>>So, to everone, MODULE_DEPEND only marks which modules are required >>>>for this module to work, it does not infulence startup ordering at >>>>all... >>> >>>So, should I commit this patch? >>> > > [...] > >>>@@ -69,3 +69,7 @@ >>>.An -nosplit >>>This manual page was written by >>>.An Alexander Langer Aq alex@FreeBSD.org . >>>+.Sh BUGS >>>+.Nm >>>+only marks which modules are required for the module to work, it does >>>+not influence start-up ordering. >> >>It also is used by the loader and by kldload to load the dependent >>modules. So it's more than just an informational tag, it actually does >>get used by the system. > > > I don't think the above says it's only informational, but I'm sure the > wording could be improved. Perhpaps somebody has a suggestion for > better describing the issue? > Well, I guess my point is that it's important to document exactly what MODULE_DEPEND does do, and well as what it doesn't do. It's not really a bug that it doesn't change SI_ORDER order, it's just a not a feature that it was ever intended to support. A second paragraph under DESCRIPTION that talks about this would probably be most appropriate. Something like: .Nm provides hints to the kernel .Xr loader 8 and to .Xr kldload 8 to ensure that the named dependency is loaded prior to the existing module. It does not change or dictate the order in which modules are initialized at runtime. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41E2F4C6.1010000>