Date: Tue, 05 Jan 1999 13:35:27 -0800 From: Mike Smith <mike@smith.net.au> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: current@FreeBSD.ORG, Mike Smith <mike@smith.net.au>, "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, Andrzej Bialecki <abial@nask.pl> Subject: Re: /boot/boot.rc && /boot/rc.d Message-ID: <199901052135.NAA01045@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 06 Jan 1999 03:18:40 %2B0900." <36925780.75AB6581@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I was thinking about possible on-comings "patches" in boot.rc > (currently known as boot.conf :), when I realized that for > third-party drivers or ports making use of loader it would better to > source files from a boot/rc.d directory. > > Is this already planned? I've been pondering different organisations for this stuff; there are a few things to consider here. The most significant being that there's a potentially valid set of reasons to want to load different module profiles, so you need a mechanism that allows you to have several different collections of module startup files. One approach, I call this the "macintosh" technique because it's similar to the way that inits/extensions are managed there: Modules live in /modules as *.ko (active) and *.kx (inactive) module initialiser scripts live as separate files alongside the modules, ie. as *.kinit. Load procedure is to simply scan the directory, and for every .ko file, read the .kinit file (if present) for the load command or simply load it with no args (and if not already loaded). This approach is nice because it's simple. You can make "profiles" by having module subdirectories with links back to the modules that you want to load (the loader groks symlinks) - there are wrinkles here. Another approach is to leave all of the .ko and .kinit files in /modules, and use a script file of some sort to nominate the modules to load/arguments etc. (overriding the .kinit files?). This makes it easy to swap profiles, one script per profile. While throwing these opposites around, consider also that some modules are going to be demand-loaded, so you only want to be listing/ nominating ones that are optional, and even then only ones that are required before the system boots. Thus I wonder if it's really necessary to have a particularly complex mechanism... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901052135.NAA01045>