I'm not sure I agree with modularising the loop device anyway, but setting that aside,
Isn't rc.modules meant to be used for this sort of thing?

But, instead of a simple
in rc.modules that can be commented out, or not as suits the admin,.

rc.S has to do a test -x on rc.loop and then sources it. Then does modinfo, lsmod and grep before deciding on whether to modprobe the module.

I know it's not a big deal, but I can't help but think that someone has lost sight of K.I.S.S. here.

Well it maybe kind of silly to argue about which rc.* file this gets done in, but I am sure it is a good idea
not to try and force load the module when it does not exist or is already loaded.

edit: Looking at rc.S rc.loop is one of the first scripts checked so I am sure there is a good reason for it, likely the same reason it has been compiled in all this time. Also making this a module allows you to change the number of allowed loop devices something people with encrypted partitions may need to do.

2 members found this post helpful.

modprobe will already contain logic to handle those situations. If you try and also deal with it in the shell script then you're really only duplicating that (and probably in a less efficient way).

As for whether it matters which rc file loads a module, my point is simply that: when you have rc.modules whose sole reason for existence is to load modules, then it seems like you really ought to use it when you need a module loading. If nothing else it maintains a consistent approach.

2 members found this post helpful.

GazL, I find your lack of faith disturbing!

First, the LOOP (module) is necessary for cryptsetup. Therefore has a special initialization.

Secondly, there are kernels that have built-in LOOP, so it takes a special processing.

Thirdly, with LOOP as a module, you can specify MAXLOOPS. By default, you can use 8 devices. Read: eight encrypted partitions and you will be out-of devices.

Finally, I see someone who wants to be more Catholic than the Pope ...

0 members found this post helpful.

First, you're wrong. cryptsetup uses device-mapper(dm-crypt). You're thinking of the old deprecated Cryptoloop encryption system (and as we recently saw in another thread: truecrypt)

Secondly, if a kernel has loop built in then modprobe will not find a module to install and it will be handled. Besides which, rc.modules is kernel specific and shouldn't contain a 'modprobe loop' when being shipped with a kernel that has it built in so the point is invalid on two separate counts.

Thirdly, As I've already said, loop is not used by dm-crypt which mitigates this point somewhat, but unless you're doing something like mounting multiple cd iso images at once, then you're unlikely to exhaust all 8 slots in normal use, but it is possible that someone might hit this limit so I concede that being able to change this at module install time has benefits. However, I wasn't making any points about it being made a module, merely about what should be doing the loading.

Finally, stick your personal comments where the sun doesn't shine!
Some people put value on the skin deep eye candy on the desktop, I value 'correctness' in the stuff that lies beneath, and to my mind rc.modules is the 'correct' place from which to load modules.
If someone can put a counter argument forward then that's fine by me, I'll listen and treat them with respect. If Pat disagrees with my thinking on this then that's also fine - it won't be the first time we've disagreed and we're still amicable. However I should be able post here raising questions like this without receiving personal insults as thanks for it, and the whole thing turning into a drama!

1 members found this post helpful.

If you think that I've insulted you, I apologize!

I did not know that this phrase is insulting for you.

In Romania (and Romanian language), the expression "Not be more Catholic than the Pope!" is a way to tell someone (using a joke), that he asks questions about very minor things that will not change anything if it is modified. It's not a insult.

Once again, I apologize!

I'd be surprised if there's a benchmarkable difference there, even on a very slow machine.

Sure, we could have used:
And in fact, that's exactly what's in the rc.S of the installer, where I tend to be less self-conscious.

I don't think there's a functional difference. These 5 lines of script are really a K.I.S.S. violation? Well, it could change, I guess...

Well, I think it's too late to load it in rc.modules for some uses. I guess we could force everyone affected by that to add it to their initrd to get around that. Is that a plan?

1 members found this post helpful.

Fair enough Darth. I'll put it down to a cultural difference.

To be more Catholic than the Pope:
To adhere more stringently to Roman Catholic practices and doctrine than is required by church doctrine; - usually used in a negative sense to mean, to be excessively pious.

Pious:
Making a hypocritical display of virtue

I'm sure you can see where that's heading. Also my opinion of the catholic church (which I won't go into for fear of offending others) didn't help matters either. Guess you were just unfortunate to pick the one phrase likely to send me Nuclear!
My apologies too for over-reacting.


I know I'm a bit of an perfectionist when it come to what are essentially very minor technical issues like this, but I really do care about doing things the 'right' way.

1 members found this post helpful.

I have to cast my vote for this algorithm being more correct

than this one

1 members found this post helpful.

There is also "modprobe -q" to stop it whining, so the redirections aren't really needed, and I certainly take your point that the performance difference is going to be unnoticeable.


My main point is that the rc.modules scripts is there to do this exact job so why not let it do it. The rest of the stuff I mentioned was really secondary.

Is there a usage case where waiting for rc.modules to run wouldn't be acceptable? The most obvious I could think of would be a filesystem in /etc/fstab that's set to automount using the loop mount option,
but perhaps the answer to that is to turn it on it's head and bring the running of rc.modules forward within rc.S?

Anyway, all I wanted to do was present the argument for consideration. If you're satisfied with how it's currently being done then it's not my place to argue with you.

And I'd agree with you if you weren't duplicating exactly what modprobe is doing internally.

If the module has already been installed then modprobe will end cleanly doing nothing.
If the module doesn't exist, then how is modprobe failing with a module not found, any different than the same error that your run of modinfo on the if would generate?

Why not skip the modinfo, and lsmod|grep and just do a

At that point in the boot, depmod is not going to be able to write to the root volume. Anyway, I would really hesitate to move that.

I don't know if I'm ever satisfied with anything. But, unless we have a problem, and a fix for it, I'm happy enough for now.

2 members found this post helpful.

If someone boots a kernel with loop built-in, I do not consider that an error, and having modprobe produce:
on the console at boot is rather obnoxious.

On the other hand, if there is a loop module, and something goes wrong loading it, I'd like to see what the error is.

1 members found this post helpful.

That's a good idea.

Since my simple need of using ext4 already requires initrd, why should those loop users' life be easier?

2 members found this post helpful.

Loading the modules seems like one of the things you really want to do as early as possible, but yes, that's a change that would need to be shaken out at the beginning of a development cycle rather than at the end of one like we are now. I wasn't suggesting this as something to be changed this late in the game, merely trying to look at the issue from another angle.

Anyway, I'll not take up any more of your time on this. Clearly there are additional things to be considered. Perhaps I'll take another look at this once current is up and moving again.

Thanks for responding Pat.