1 |
Hi all, |
2 |
Do we have a policy about init scripts loading modules? I didn't think |
3 |
the scripts for any packages that I have installed load modules, but I |
4 |
don't have everything installed. It seems like the preferred way to do it |
5 |
is to have the admin put any necessary modules in /etc/modules.autoload. |
6 |
|
7 |
Here is why I ask. The pcmcia init script that is installed with |
8 |
pcmcia-cs currently is outdated, but it loads the $PCIC (i82365 or |
9 |
yenta_socket) module, as well as pcmcia_core and ds. Then it starts |
10 |
cardmgr (which will not start without ds loaded). The init script does not |
11 |
unload the modules when it is stopped, though. |
12 |
|
13 |
It makes sense that if a service requires particular kernel |
14 |
functionality to be available in order to work that it should load the |
15 |
modules for that functionality. However, this adds some overhead to the |
16 |
initscript, in that you have to determine if the module exists, load it, |
17 |
make sure it loads, etc. before starting the service. Then what about when |
18 |
the functionality has been built into the kernel, not as a module. Do we |
19 |
have to detect that? That is why I think it might be easier if we make it |
20 |
policy to just eerror out and say "You have to first load these modules!" |
21 |
rather than worrying about loading them in the script. |
22 |
|
23 |
If we decide to load modules from the scripts, then it would be nice to |
24 |
have some convenience routines to facilitate the process, e.g., |
25 |
|
26 |
load_modules pcmcia_core i82365 ds || die |
27 |
|
28 |
or something like that, which would check to see if the modules were |
29 |
already loaded (or maybe even compiled into the kernel), and if not, then |
30 |
it would load them. |
31 |
|
32 |
Thoughts? |
33 |
|
34 |
Chad |