Loading a module multtiple times

Loading a module multtiple times

[Randy.Dunlap]

Hi Rusty-

I was looking into a bug in /proc/net/dev truncated output.
/proc/net/dev lists {if (!buggy)} all loaded network interfaces.

To get a large number of network interfaces, Christian (below)
told me to copy driver/net/dummy.o to several different file names
and then insmod them.  It seems to have worked for him, and it works
that way in 2.4.recent, but it's not working for me.  See error
messages below.

Which way is expected behavior?
What should be the expected behavior?
or am I just seeing bugs (failures) that noone else sees?

It seems like not supporting this is likely to cause some problems.

Thanks,
~Randy


(was: [BUG 2.5.67 (and probably earlier)] /proc/dev/net doesnt show all net devices)

On Wed, 30 Apr 2003 09:11:11 +0200 Christian Bornträger <linux@borntraeger.net> wrote:


| > How do I configure the dummy network driver to get loads of interfaces?
| 
| Just copy the dummy.o to dummy1.o dummy2.o dummy3.o,  insmod and ifconfig 
| them.

Doesn't work for me.  insmod (from ver. 0.9.11a module-init-tools)
won't load multiple copies of dummy[n].o or dummy[n].ko.
(with dummy already loaded)

For the .o files, it says:
  dummy: no version magic, tainting kernel.
  Error inserting 'dummy1.o': -1 File exists

and for the .ko files, it says:
  Error inserting 'dummy1.ko': -1 File exists
---

Re: Loading a module multtiple times

[Kai Germaschewski]

On Wed, 30 Apr 2003, Randy.Dunlap wrote:

> To get a large number of network interfaces, Christian (below)
> told me to copy driver/net/dummy.o to several different file names
> and then insmod them.  It seems to have worked for him, and it works
> that way in 2.4.recent, but it's not working for me.  See error
> messages below.
> 
> Which way is expected behavior?
> What should be the expected behavior?

This failure is expected behavior, AFAICT. The module.ko has the module 
name embedded and thus duplicate insertion will be recognized even when 
the .ko file has been renamed.

To allow insertion of a module under a new name, you have to give
module-init-tools some new option (which I can't remember right now).

--Kai

Re: Loading a module multtiple times

[Rusty Russell]

In message <20030430140557.12e13f1a.rddunlap@osdl.org> you write:
> 
> Hi Rusty-
> 
> I was looking into a bug in /proc/net/dev truncated output.
> /proc/net/dev lists {if (!buggy)} all loaded network interfaces.
> 
> To get a large number of network interfaces, Christian (below)
> told me to copy driver/net/dummy.o to several different file names
> and then insmod them.  It seems to have worked for him, and it works
> that way in 2.4.recent, but it's not working for me.  See error
> messages below.
> 
> Which way is expected behavior?
> What should be the expected behavior?
> or am I just seeing bugs (failures) that noone else sees?

No, it's a 2.5 thing: modules know their own name.  This is because
(1) the names are used to set new-style boot parameters, (2) needing
to insert two modules is usually wrong, since how would that work if
the module was built-in?

It also opens us up to the possibility of a list of built-in modules,
if we wanted to.

However, the -o option to modprobe replaces the module name (by
hacking the elf object, yes), because programmers are basically lazy,
and multiple modules are useful for testing.

So, you want:
	for i in `seq 1 100`; do modprobe -o dummy$i dummy; done

This works on 2.4 as well.  Note that insmod doesn't support -o, being
a trivial program by design.

> It seems like not supporting this is likely to cause some problems.

Yes.  Removing any feature causes problems 8(.  But adding every
feature is usually worse.

Hope this clarifies?
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: Loading a module multtiple times

[Randy.Dunlap]

> In message <20030430140557.12e13f1a.rddunlap@osdl.org> you write:
>>
>> Hi Rusty-
>>
>> I was looking into a bug in /proc/net/dev truncated output.
>> /proc/net/dev lists {if (!buggy)} all loaded network interfaces.
>>
>> To get a large number of network interfaces, Christian (below)
>> told me to copy driver/net/dummy.o to several different file names and
>> then insmod them.  It seems to have worked for him, and it works that way
>> in 2.4.recent, but it's not working for me.  See error
>> messages below.
>>
>> Which way is expected behavior?
>> What should be the expected behavior?
>> or am I just seeing bugs (failures) that noone else sees?
>
> No, it's a 2.5 thing: modules know their own name.  This is because (1) the
> names are used to set new-style boot parameters, (2) needing to insert two
> modules is usually wrong, since how would that work if the module was
> built-in?
>
> It also opens us up to the possibility of a list of built-in modules, if we
> wanted to.
>
> However, the -o option to modprobe replaces the module name (by
> hacking the elf object, yes), because programmers are basically lazy, and
> multiple modules are useful for testing.
>
> So, you want:
> 	for i in `seq 1 100`; do modprobe -o dummy$i dummy; done
>
> This works on 2.4 as well.  Note that insmod doesn't support -o, being a
> trivial program by design.

Argh, I looked thru insmod.c but not modprobe.c for a solution.

>> It seems like not supporting this is likely to cause some problems.
>
> Yes.  Removing any feature causes problems 8(.  But adding every
> feature is usually worse.
>
> Hope this clarifies?

Yes, thanks much.

~Randy

Re: Loading a module multtiple times

[Rusty Russell]

In message <33490.4.64.196.31.1051765837.squirrel@www.osdl.org> you write:
> Argh, I looked thru insmod.c but not modprobe.c for a solution.

Well, you *could* do:

	for i in `seq 1 9`; do
		sed "s/dummy/dumm$i/g" < dummy.ko > dumm$i.ko
		insmod dumm$i.ko
	done

But don't 8)

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: Loading a module multtiple times

[Alan Cox]

On Iau, 2003-05-01 at 07:22, Rusty Russell wrote:
> In message <33490.4.64.196.31.1051765837.squirrel@www.osdl.org> you write:
> > Argh, I looked thru insmod.c but not modprobe.c for a solution.
> 
> Well, you *could* do:
> 
> 	for i in `seq 1 9`; do
> 		sed "s/dummy/dumm$i/g" < dummy.ko > dumm$i.ko
> 		insmod dumm$i.ko
> 	done
> 
> But don't 8)

The dummy driver expects insmod -o dummy1 dummy; insmod -o dummy2 dummy
etc to be usable. You don't normally need lots of dummy drivers nowdays
since you can give one lots of addresses

Re: Loading a module multtiple times

[Chuck Ebbert]

> No, it's a 2.5 thing: modules know their own name.  This is because
> (1) the names are used to set new-style boot parameters, (2) needing
> to insert two modules is usually wrong, since how would that work if
> the module was built-in?
> 
> It also opens us up to the possibility of a list of built-in modules,
> if we wanted to.

  The list of built-ins would be really, really nice -- it would
beat the heck out of digging through the .config and/or going
back to the build machine and doing 'make menuconfig' just to
see what's in there.

------
 Chuck

Loading a module multtiple times

[Chuck Ebbert]

Randy Dunlap wrote:

>  Error inserting 'dummy1.ko': -1 File exists

  Duplicate kobject/sysfs name?

------
 Chuck