Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Demand loadable modules?

0 views
Skip to first unread message

Terry Evans

unread,
Feb 16, 1994, 9:06:31 PM2/16/94
to
Let me know if this is way of base or has been done.

I was just reading through my mail and saw mail to make the iBCS stuff
as a loadable module when the thought came to me "Why can't we just
demand load any needed modules?"

I was just thinking that it would be nice to have the iBCS module
hooked into the kernel, but only load it when I need to run an iBCS
module, then, perhaps after some given time of un-use it would de-load
itself to free up memory.

Perhaps there would be some way to configure something like this as
demand-load the module or always have it loaded.

Just a few thoughts. Please send any comments, suggestions, flames,
whatevers so I can look at you reasoning as to why this would or wouldn't
be a good idea.

Terry
tev...@cs.utah.edu

John Paul Morrison

unread,
Feb 17, 1994, 3:31:57 AM2/17/94
to
In article <1994Feb16.1...@hellgate.utah.edu>,

Terry Evans <tevans%sunset....@cs.utah.edu> wrote:
> Let me know if this is way of base or has been done.
>
>I was just reading through my mail and saw mail to make the iBCS stuff
>as a loadable module when the thought came to me "Why can't we just
>demand load any needed modules?"

I'm not a kernel guru, but wouldn't it be more consistent to make the
kernel itself demand loadable? Then there wouldn't need to be a
special case for modules; and pages anywhere in the kernel (except the
paging code!!!) would get swapped in and out as needed.
I don't imagine this is an easy task.


There's another issue: device majors/minor. I think I heard people
were looking into this. Why not dynamically allocate device majors
for modules (or for all devices)? Something like:

insmod foo.o /dev/foo

or something like that. You wouldn't have to worry about mknod'ing devices.

I don't think it's a big issue right now, esp. with the bigger goal of
Linux 1.0, but people have converted most Linux drivers into modules,
such as filesystems, SCSI, sound etc. ethernet modules might get done
when the net code is "finished". It'll be confusing managing all those
loadable drivers.

I think the serial code for one, is dependent on the major number, but
most things could be dynamically allocated, because they don't care
what the number is. Drivers that get compiled in the kernel could have
the major/minor assigned ahead of time, and modules could be assigned
dynamically. If it can't be automagically assigned, then insmod should
at least let you override the default at the command line.

>Terry
>tev...@cs.utah.edu


--
--------------------------------------------------------------------------
BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM --
jmor...@bogomips.ee.ubc.ca jmor...@rflab.ee.ubc.ca
--------------------------------------------------------------------------

Terry Evans

unread,
Feb 17, 1994, 8:34:18 AM2/17/94
to
I hate to follow up to my own post, but I guess I wasn't very clear
on exactly what I meant. I am looking at a situation like the following:

Normal user tries to run a program that relies on a module (iBCS for example)
Kernel realizes the module isn't loaded
Kernel loads module
User program continues
After some period of unuse, kernel unloads module

Sorry if it wasn't clear the first time what I was looking for. In
short I wanted a way for the kernel to load and unload
modules without the superuser having to do it.

Terry
tev...@cs.utah.edu

Doug DeJulio

unread,
Feb 17, 1994, 7:52:10 PM2/17/94
to
In article <1994Feb17....@bogomips.ee.ubc.ca>,

John Paul Morrison <jmor...@bogomips.ee.ubc.ca> wrote:
>>I was just reading through my mail and saw mail to make the iBCS stuff
>>as a loadable module when the thought came to me "Why can't we just
>>demand load any needed modules?"
>
>I'm not a kernel guru, but wouldn't it be more consistent to make the
>kernel itself demand loadable? Then there wouldn't need to be a
>special case for modules; and pages anywhere in the kernel (except the
>paging code!!!) would get swapped in and out as needed.
>I don't imagine this is an easy task.

You can't do it for the *entire* kernel. Some parts of it have to
stay resident. Also, some device drivers may flake out if you do
this, because the environment they're running in becomes less of a
realtime one. You can't really have swapping in a realtime app, at
least not easlily.

--
Doug DeJulio
dd...@cmu.edu

Eric J. Schwertfeger

unread,
Feb 18, 1994, 12:45:33 AM2/18/94
to
In article <1994Feb17....@bogomips.ee.ubc.ca> jmor...@bogomips.ee.ubc.ca (John Paul Morrison) writes:
>In article <1994Feb16.1...@hellgate.utah.edu>,
>Terry Evans <tevans%sunset....@cs.utah.edu> wrote:
>> Let me know if this is way of base or has been done.
>>
>>I was just reading through my mail and saw mail to make the iBCS stuff
>>as a loadable module when the thought came to me "Why can't we just
>>demand load any needed modules?"
>
>I'm not a kernel guru, but wouldn't it be more consistent to make the
>kernel itself demand loadable? Then there wouldn't need to be a
>special case for modules; and pages anywhere in the kernel (except the
>paging code!!!) would get swapped in and out as needed.
>I don't imagine this is an easy task.

I think that is an understatement :-) Remember the swapping code
needs to call devices to do the actual swapping, which can currently
be any local device, and someday could be a network device. These
devices can then call arbitrary support routines, etc. By the time
you get done, it's easier to say what in the kernel is swappable,
rather than what isn't.
--
Eric J. Schwertfeger, man...@cs.unlv.edu

John Burton

unread,
Feb 19, 1994, 5:54:22 AM2/19/94
to
In article <1994Feb18.0...@unlv.edu> man...@unlv.edu writes:

>In article <1994Feb17....@bogomips.ee.ubc.ca>


>
>I think that is an understatement :-) Remember the swapping code
>needs to call devices to do the actual swapping, which can currently
>be any local device, and someday could be a network device. These
>devices can then call arbitrary support routines, etc. By the time
>you get done, it's easier to say what in the kernel is swappable,
>rather than what isn't.

Couldn't you make the system call to add a swap device disable swapping
on the pages used by a device driver. I agree that the support routines
would be a problem, but I should think you could add a hunded K or so
of swappable memory by doing this which would no doubt be a huge
advantage to those with little memory.


--
John Burton

0 new messages