Hello everyone,
First of all, let me get one thing clear: I really like what has been
done in the 2.5/2.6 kernel branch and am full of admiration for the
efforts of everyone who made it possible. In fact, I've been following
the new line since late 2.5s and am running 2.6.4 right now... I'll say
that again, it's a fine piece of work.
However, there have been some - pretty much minor considering the whole
image, but rather annoying neverthless - issues which make the
experience far from the optimum. Knowing "stable" doesn't necessarily
equal "mature", I waited for them to be resolved and indeed most of them
have; now that 2.6.4 has been released and the list has shrunk to minute
size, I've decided to share my reservations and (it is quite likely that
some of these things only require an answer and not a bug fix) with the
High Instance.
Anyhow, what I still don't quite like, or would like to know more, about
the 2.6.x branch:
1. Matrox framebuffer keeps on messing up the consoles when I have X
running and switch back and forth. As far as I know this problem is
known to you (in fact, I use the temporary workaround patch Petr has
released which as far as I can see only leaves the issue of scrolling
lines occasionally losing the screen bottom, especially with programs
using ncurses) and besides things seem to have got much better thanks to
the general-fbcon patches introduced in 2.6.3 and 2.6.4, so I only
mention it here pro forma.
2. While fbcon is active, setfont only works on the foreground VT. It
happens with X both running and not running, as well as on both matroxfb
and vesafb (I haven't tested the others); I don't think this is a kbd
bug (my version is 1.10 and I don't see anything in the 1.10->1.12
changelog which could be related with the issue). Hope this one gets
fixed soon, as it's the most annoying of the whole bunch.
3. Junk left in the source root after 'make clean'. Is it really
supposed to stay there? If so, could I get told why? By "it" I mean the
two .tmp_vmlinux and the four .tmp_kallsyms files, taking up
approximately 8 MB of disk space on my system.
4. Module autounloading. Is it actually possible? Will it be possible?
If not, why? The old method of periodically invoking "modprobe -ras" via
cron doesn't seem to accomplish anything and I really liked the idea of
keeping only the required modules in memory at any given moment without
having to log in as root to unload the unneeded ones - after all, if the
autoloader can only add them what's the point of not going the
monolithic way? The docs on the new approach towards modules are
virtually nonexistent in the kernel source package and while I suppose I
could simply write a script which would scan the list of
currently-loaded modules for the unused ones and remove them one by one,
but this approach feels terribly crude comparing with the elegance of
the old solution. I use module-init-tools-3.0, a serious improvement
over 0.9.15 if I may say so but, unless I'm thinking about it with
completely wrong base assumptions, still far from perfect.
That's all. Not much, isn't it? Since at least in case of the latter two
I seem to be wandering in the dark rather than facing actual bugs, I'll
be grateful for all the explanations and sound advice you'd care to give
me. And once again, keep up the good work!
Regards,
--
MS
> 4. Module autounloading. Is it actually possible? Will it be possible?
> If not, why? The old method of periodically invoking "modprobe -ras" via
> cron doesn't seem to accomplish anything and I really liked the idea of
> keeping only the required modules in memory at any given moment without
> having to log in as root to unload the unneeded ones - after all, if the
> autoloader can only add them what's the point of not going the
> monolithic way? The docs on the new approach towards modules are
> virtually nonexistent in the kernel source package and while I suppose I
> could simply write a script which would scan the list of
> currently-loaded modules for the unused ones and remove them one by one,
> but this approach feels terribly crude comparing with the elegance of
> the old solution. I use module-init-tools-3.0, a serious improvement
> over 0.9.15 if I may say so but, unless I'm thinking about it with
> completely wrong base assumptions, still far from perfect.
As far as I know, the new preffered way of handling modules, is to load
them when device is detected (hotplug and udev, at boot or later)
and (optionally) remove when device is removed, not as in older kernels,
when module was added or removed depending on its use. This way (as
opposed to monolithic kernel) you can have "generic" kernel by placing
everything in modules. And what is the point in unloading not currently
needed modules? They should not use much resources when not needed...
And if you want to put your system to sleep, you must put to sleep all
devices (in the right order) *including* these not currently used but
present in the system. If you will not do this, you can probably get big
crash. So you need loaded module, that knows how to put device to sleep.
Grzegorz Kulewski
On Sat, 13 Mar 2004, Marek Szuba wrote:
[Snip]
> 4. Module autounloading. Is it actually possible? Will it be possible?
> If not, why? The old method of periodically invoking "modprobe -ras" via
> cron doesn't seem to accomplish anything and I really liked the idea of
> keeping only the required modules in memory at any given moment without
> having to log in as root to unload the unneeded ones - after all, if the
> autoloader can only add them what's the point of not going the
> monolithic way? The docs on the new approach towards modules are
> virtually nonexistent in the kernel source package and while I suppose I
> could simply write a script which would scan the list of
> currently-loaded modules for the unused ones and remove them one by one,
> but this approach feels terribly crude comparing with the elegance of
> the old solution. I use module-init-tools-3.0, a serious improvement
> over 0.9.15 if I may say so but, unless I'm thinking about it with
> completely wrong base assumptions, still far from perfect.
Safe module unloading is a very difficult problem. So much so that
disallowing unloading modules completely has been discussed in the past.
Digging around an lkml archive for more info on why module unloading is
inherently problematic, and not at all easy to do (well, not at all easy
to do well) is recommended.
--
Alex Goddard
agoddard at purdue dot edu
On Sat, Mar 13, 2004 at 07:27:12PM +0100, Marek Szuba wrote:
>
> 3. Junk left in the source root after 'make clean'. Is it really
> supposed to stay there? If so, could I get told why? By "it" I mean the
> two .tmp_vmlinux and the four .tmp_kallsyms files, taking up
> approximately 8 MB of disk space on my system.
Already addressed and included lastest snapshot of Linus's tree.
See http://linus.bkbits.net:8080/linux-2.5/[email protected]?nav=index.html|ChangeSet@-2d
[Do not expect link to work for more than a few hours or days, since cset numbers
may vary over time]
The fix will show up in 2.6.5.
But thanks for the input!
Sam
Grzegorz Kulewski wrote:
>>4. Module autounloading. Is it actually possible? Will it be possible?
>>If not, why? The old method of periodically invoking "modprobe -ras" via
>>cron doesn't seem to accomplish anything and I really liked the idea of
>>keeping only the required modules in memory at any given moment without
>>having to log in as root to unload the unneeded ones - after all, if the
>>autoloader can only add them what's the point of not going the
>>monolithic way? The docs on the new approach towards modules are
>>virtually nonexistent in the kernel source package and while I suppose I
>>could simply write a script which would scan the list of
>>currently-loaded modules for the unused ones and remove them one by one,
>>but this approach feels terribly crude comparing with the elegance of
>>the old solution. I use module-init-tools-3.0, a serious improvement
>>over 0.9.15 if I may say so but, unless I'm thinking about it with
>>completely wrong base assumptions, still far from perfect.
>
>
> As far as I know, the new preffered way of handling modules, is to load
> them when device is detected (hotplug and udev, at boot or later)
> and (optionally) remove when device is removed, not as in older kernels,
> when module was added or removed depending on its use. This way (as
> opposed to monolithic kernel) you can have "generic" kernel by placing
> everything in modules. And what is the point in unloading not currently
> needed modules?
It enables you to update a module (e.g. to fix a bug) without having to
do a reboot. I think that people trying to use Linux for useful work
would find this useful. So unloadable modules is certainly a
functionality worth aiming for.
> They should not use much resources when not needed...
> And if you want to put your system to sleep, you must put to sleep all
> devices (in the right order) *including* these not currently used but
> present in the system. If you will not do this, you can probably get big
> crash. So you need loaded module, that knows how to put device to sleep.
>
>
> Grzegorz Kulewski
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Dr Peter Williams, Chief Scientist [email protected]
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
On Wed, 17 Mar 2004, Helge Hafting wrote:
> Alex Goddard wrote:
> [...]
> >
> > Safe module unloading is a very difficult problem. So much so that
> > disallowing unloading modules completely has been discussed in the past.
> > Digging around an lkml archive for more info on why module unloading is
> > inherently problematic, and not at all easy to do (well, not at all easy
> > to do well) is recommended.
>
> Safe unloading is hard for a few oddball modules that probably shouldn't
> be modules at all but rather be part of some larger module. Is it necessary
> to have modules for various parts of iptables, instead of stuffing
> everything in a big "ipv4" module?
That is not the impression I got from this post:
http://marc.theaimsgroup.com/?l=linux-kernel&m=104554480315013&w=2
This thread is the other one that came to mind:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105915495603446&w=2
In one post in the thread spawned by the second URL's post, Alan Cox
suggests a plan vaguely similar to what you outlined below what I've
quoted (ie: a MODULE_UNLOADABLE flag or something for those modules that
_can_ be easily unloaded).
However, the general impression I get from that thread on removing module
refcounting is that in general unloading modules is tricky. Not
unsolvable. Just tricky.
--
Alex Goddard
agoddard at purdue dot edu
On Wed, 17 Mar 2004 17:27:50 -0500 (EST)
Alex Goddard <[email protected]> wrote:
> On Wed, 17 Mar 2004, Helge Hafting wrote:
>
> > Alex Goddard wrote:
> > [...]
> > >
> > > Safe module unloading is a very difficult problem. So much so that
> > > disallowing unloading modules completely has been discussed in the past.
> > > Digging around an lkml archive for more info on why module unloading is
> > > inherently problematic, and not at all easy to do (well, not at all easy
The problem for must users of earlier versions of linux is the definition of
safe changed. Safe now means you can remove the module without crashing
the kernel. Safe used to mean that nothing could possible be using the code.
Sort of like difference between NFS hard and soft mount.
A bigger issue is that there seems to be a whole set of smaller distro's and
people who write their own startup scripts that became addicted to the old behaviour.
I wish all the distro's would get rid of explicit modprobe and rmmod's in startup
scripts.
> 1. Matrox framebuffer keeps on messing up the consoles when I have X
> running and switch back and forth. As far as I know this problem is
> known to you (in fact, I use the temporary workaround patch Petr has
> released which as far as I can see only leaves the issue of scrolling
> lines occasionally losing the screen bottom, especially with programs
> using ncurses) and besides things seem to have got much better thanks to
> the general-fbcon patches introduced in 2.6.3 and 2.6.4, so I only
> mention it here pro forma.
I need to get around to fixing that problem. I'm glad the general patch
that went in fixed alot of problems :-) It's a matter of the framebuffer
driver restoring its state when switching back to the console. Most
drivers have a problem with that. The current approach is to use the
xxfb_blank function to fix this up.
> 2. While fbcon is active, setfont only works on the foreground VT. It
> happens with X both running and not running, as well as on both matroxfb
> and vesafb (I haven't tested the others); I don't think this is a kbd
> bug (my version is 1.10 and I don't see anything in the 1.10->1.12
> changelog which could be related with the issue). Hope this one gets
> fixed soon, as it's the most annoying of the whole bunch.
This is normal behavior. In 2.4.X you have the same behavior. Only vgacon
doesn't do this because it doesn't handle the differences in screen size
on VC switching.