Quotes of the week [LWN.net]

Quotes of the week

Posted Dec 1, 2011 2:17 UTC (Thu) by jcm (subscriber, #18262) [Link]

A lot of songs have such alternative meanings in my head. I should make a list.

Quotes of the week

Posted Dec 1, 2011 2:18 UTC (Thu) by thedevil (guest, #32913) [Link] (2 responses)

It's fairly hard to know what precisely you need to enable in a hand built kernel, these days. Is there a shortcut to determine that?

Quotes of the week

Posted Dec 1, 2011 3:22 UTC (Thu) by dkrawchuk (guest, #21896) [Link] (1 responses)

Copy the config file for the kernel that you are running from /boot to .config. Then plug in all of the accessories that you normally use and run make localmodconfig. That should give you a good start.

Quotes of the week

Posted Dec 2, 2011 3:52 UTC (Fri) by thedevil (guest, #32913) [Link]

"all of the accessories that you normally use"

There's the catch. I can't even plug them all in at once (not enough USB connectors). And what about those that currently sit in the drawer, but I may someday reuse them? I don't want to suddenly be forced to recompile the kernel then.

Quotes of the week

Posted Dec 1, 2011 10:44 UTC (Thu) by nlucas (guest, #33793) [Link] (7 responses)

It's obvious Linus never tried to compile a minimalist generic kernel.

There are drivers who don't even work well unless loaded as module (many usb ones included).

Heck, the ehci-hcd driver (USB 2.0 hci) must be a module if you have some crappy BIOS, because you need to unload it for poweroff to work (will reboot if loaded, instead). And this is the driver that now claims in dmesg that it needs to be loaded before any other hci driver (which can only be done if the other "hardware" hci drivers are modules and udev configured for that).

Quotes of the week

Posted Dec 1, 2011 11:10 UTC (Thu) by neilbrown (subscriber, #359) [Link]

> It's obvious Linus never tried to compile a minimalist generic kernel.

An alternate interpretation is that Linus did, and fixed all the problems that affected him on his hardware. :-)

Quotes of the week

Posted Dec 1, 2011 14:11 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (3 responses)

Heck, the ehci-hcd driver (USB 2.0 hci) must be a module if you have some crappy BIOS, because you need to unload it for poweroff to work (will reboot if loaded, instead).

Is there a bug report, and is it idle, work-in-progress, or closed WONTFIX? Because (regardless of the deficiencies of the BIOS) that driver sounds buggy to me.

Quotes of the week

Posted Dec 1, 2011 14:51 UTC (Thu) by nlucas (guest, #33793) [Link] (2 responses)

I'm not the original discover of the issue. I just found about it by googling for a fix and found that some distros already fix this somehow.

I can't know if there is any open/closed bug for this. Kernel bugzila is still down.

Quotes of the week

Posted Dec 1, 2011 19:22 UTC (Thu) by mlankhorst (subscriber, #52260) [Link] (1 responses)

well my system currently refuses to shut down completely too. It forgets suspend to ram and wakes up after a few seconds, cleaning everything in memory.. Powerdown acts the same way, turning back on after a few seconds too. So link please? :P

Quotes of the week

Posted Dec 1, 2011 20:05 UTC (Thu) by nlucas (guest, #33793) [Link]

This was some time ago, but my current google-fu gets me this links that may help you:

http://www.thinkwiki.org/wiki/Problems_with_ACPI_suspend-...
http://www.thinkwiki.org/wiki/How_to_make_ACPI_work
https://bbs.archlinux.org/viewtopic.php?pid=942749

Note that in all three, one of the advises for fixing rebooting instead of shutting down is a "rmmod ehci-hcd" before the "poweroff" command.

Quotes of the week

Posted Dec 2, 2011 2:05 UTC (Fri) by Alan.Stern (subscriber, #12437) [Link] (1 responses)

I bet ehci-hcd does not need to be unloaded before poweroff; unbinding it should work just as well. Sure, it would be nice to fix this -- but if it's caused by a crappy BIOS then fixing it won't be easy.

Although ehci-hcd claims it should be loaded before ohci-hcd and uhci-hcd, this isn't really necessary. The only reason is to avoid unlikely problems when a high-speed device is first initialized at full speed and then switched over to high speed when ehci-hcd gets going.

Quotes of the week

Posted Dec 5, 2011 13:49 UTC (Mon) by nlucas (guest, #33793) [Link]

Only today I could test that theory and you were right: unbind also solves the problem.

Now we only need some kernel hacker to look into this... (my experience with the kernel mailing list is not too famous).

Quotes of the week

Posted Dec 1, 2011 17:38 UTC (Thu) by marcH (subscriber, #57642) [Link] (6 responses)

As a driver developer, are you supposed to reboot every time you want to run a new line of code?

Quotes of the week

Posted Dec 1, 2011 18:27 UTC (Thu) by mlankhorst (subscriber, #52260) [Link] (4 responses)

Erm, linus' point was about modules you don't need, when you are working on a specific module, he never said not to load it as module, just dont build modules you dont use. ;-)

Quotes of the week

Posted Dec 1, 2011 21:08 UTC (Thu) by gidoca (subscriber, #62438) [Link] (3 responses)

Then why does it say: "Modules are evil"?

loadable kernel modules are evil

Posted Dec 2, 2011 19:15 UTC (Fri) by giraffedata (guest, #1954) [Link] (2 responses)

Right. In addition to saying not to compile modules you don't use, he said to statically link the ones that you do compile into the base kernel. With the reduced amount, that is practical and it has the benefit that no hacker can change the code.

I'm sure he didn't mean for it to apply to someone developing the module, though.

Also, it seems like a poor idea to test kernel code on a system important enough to care about security. I always use a separate expendable, impotent, minimal test system for that. In fact, it's about as quick and easy to reboot that test system as to reload a module.

loadable kernel modules are evil

Posted Dec 2, 2011 21:52 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> I'm sure he didn't mean for it to apply to someone developing the module, though.

What makes you sure? Other quotes?

> In fact, it's about as quick and easy to reboot that test system as to reload a module

How long is that?

loadable kernel modules are evil

Posted Dec 2, 2011 22:41 UTC (Fri) by giraffedata (guest, #1954) [Link]

I'm sure he didn't mean for it to apply to someone developing the module, though.
What makes you sure? Other quotes?

Only that I credit Linus with common sense and because Linus, like most people, but more, often makes terse, sweeping generalizations that aren't intended to cover every corner case.

In fact, it's about as quick and easy to reboot that test system as to reload a module
How long is that?

Now that you make me think about it, my own experience doesn't make the point. I use loadable modules, and I'm including in the time to reload the module the time it takes to generate it. If I have to reboot, the system is generally insmod-ready by the time I have the next iteration of the module ready. (On my ancient hardware, it's 20 seconds).

On modern hardware, I suspect I could get a kernel test system up in a few seconds. Maybe that changes the equation to where statically binding your test code into the base kernel is as fast and easy as loading it dynamically.

Quotes of the week

Posted Dec 11, 2011 4:06 UTC (Sun) by joern (guest, #22392) [Link]

> As a driver developer, are you supposed to reboot every time you want to run a new line of code?

Mostly you are supposed to write good code. ;)

I personally actually like to reboot every time I want to run a new line of code. With a good setup, it should take on the order of 30s, including compile time, to do so. Reducing this time by using modules may have the drawback of sometimes not working (crashed kernel) and sometimes giving bad results (different performance depending on cache warmth, state from previous tests affecting the current test, etc.).

But if modules work well for you, go for it!

Quotes of the week

Posted Dec 1, 2011 22:16 UTC (Thu) by geuder (subscriber, #62854) [Link] (12 responses)

How many users are able to configure their own kernel? Is it realistic to assume that the number will grow in future? Does Linus want to reduce the number of Linux users even further? At least on the desktop we are a often neglected minority already. The quote might be taken out of context, but I have serious trouble to understand what he wants to achieve here.

Of course distro kernels are bloated from each indivual machine's poimt of view. But what's the alternative? Sounds a bit like the old argument that compilers are evil, because good assembler progrmmers can produce slimmer code.

If the kernel community were serios about this they would need to develop some autoconfiguration + automatic build type of "mega JIT" system, so the naive user could get his custom kernel built and even rebuilt later on the fly. Maybe not completely infeasible, but still lightyears from reality. And as I wrote, I don't get the point.

Quotes of the week

Posted Dec 1, 2011 22:35 UTC (Thu) by marcH (subscriber, #57642) [Link] (11 responses)

It does not seem infeasible to compile and load a driver whenever a new device is detected or feature accessed for the first time. A bit slow, but still faster than downloading and installing an (often bloated) Windows driver.

Then, a full kernel compilation starts in the background. On the next boot a module-less kernel boots again.

All this looks technically feasible but, why the effort? Which problem would this solve?

Nothing because you've ignored the problems with modules in first place...

Posted Dec 2, 2011 8:32 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

The problem with modules are the ability to insert arbitrary code in "ring 0" core. This is security risk. They also make debugging harder because code in memory may differ from code in kernel image. You solution throws the child with the bathwater: you have solution which still have all the problems of system with a lot of modules and it suffers from problems of module-less system.

Quite an achievement, I'd say...

Nothing because you've ignored the problems with modules in first place...

Posted Dec 2, 2011 8:48 UTC (Fri) by marcH (subscriber, #57642) [Link]

Having personal problems lately? Wanna share?

Nothing because you've ignored the problems with modules in first place...

Posted Dec 4, 2011 1:38 UTC (Sun) by mab (guest, #314) [Link]

Maybe we need some sort of micro kernel :)

Quotes of the week

Posted Dec 2, 2011 22:01 UTC (Fri) by jzbiciak (guest, #5246) [Link] (7 responses)

It'd help solve the problem of extended uptime every time you plug in some new gadget your computer hadn't seen yet. Great for users nostalgic for Windows.

Quotes of the week

Posted Dec 2, 2011 22:04 UTC (Fri) by jzbiciak (guest, #5246) [Link]

To make the experience complete, though, it should require you to have the driver source on a CD (or CD-R), complete with autorun crapware and needless splash screens. (Disable-able, but only if you're good with gconf, of course.)

Quotes of the week

Posted Dec 2, 2011 23:33 UTC (Fri) by nix (subscriber, #2304) [Link] (5 responses)

Oh, come on. How often do you *buy* new gadgets?

Now, how often do new -stable kernels come out?

Reboots for new gadgetry would be a small proportion of the total number of reboots you have to do anyway.

Quotes of the week

Posted Dec 3, 2011 15:38 UTC (Sat) by jzbiciak (guest, #5246) [Link] (2 responses)

Really?

I've plugged at least three new (as in, this computer hadn't seen them before) gadgets since my last reboot 227 days ago. (TASCAM external ADC, a TI DSP EVM and a USB-to-serial cable.) And those are just the three I remember. I don't remember if I plugged my wife's phone in or not, for example. One of these days, I'll be moving the scanner over to my computer, and I know my machine hasn't seen it before.

I try to reboot at most 1 - 2 times a year at most, once my system's stable.

And it doesn't have to be that you bought the gadget new. It has to be a new-to-this-computer gadget that doesn't have the appropriate driver. "Hey Mom, before you leave, can I grab that photo you took of the two of us off your camera?" *plugs it in* "One moment please. Now reboot." If I happen to upgrade before the next time she visits... am I up for another such reboot?

I guess that brings up a second question: Would you retain the list of drivers you've "faulted in" so that the next time a vendor sends you a security patch, or the next time you upgrade your OS, you don't have to re-fault in all your gadgets? And is there an option for a batch mode? "Thank you for installing LatestShinyDistro overtop of LostItsLustre Distro. Find everything you own that you'll want to hot-plug into a USB port, and I'll go build you a proper kernel. Press enter when done." Uh, no.

Quotes of the week

Posted Dec 4, 2011 0:55 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

How can you be rebooting that rarely without leaving great big gaping security holes?

Quotes of the week

Posted Dec 4, 2011 2:07 UTC (Sun) by jzbiciak (guest, #5246) [Link]

Well, it's on a private network behind a firewall, with only one port open to the world running an up-to-date sshd. (I do regularly compile the latest updates.) There are no ports forwarded from the firewall to this machine. I have two user accounts on this machine: mine and my wife's, and currently my wife's account doesn't have a valid password set, and so is disabled.

I trust everyone that uses my private network (my wife and a couple friends).

Sure, someone *could* try to hack my WiFi and then try to find a remote root vulnerability that doesn't require an open port, and then try to guess my 8 character randomly generated alphanumeric password, but really, I'm not too worried about this machine.

Quotes of the week

Posted Dec 3, 2011 18:31 UTC (Sat) by elanthis (guest, #6227) [Link] (1 responses)

Who said anything about buying new gadgets?

Those of us with friends and colleagues often have requests to plug in random bits of equipment for some quick something-er-other. Having to wait for a recompile and a reboot certainly would make people "nostalgic" for Windows (which does not require that kind of crap, hasn't for many many years, and only the odd driver with an idiotic installer script even asks the user to consider rebooting these days).

Quotes of the week

Posted Dec 8, 2011 16:48 UTC (Thu) by nye (subscriber, #51576) [Link]

>Windows (which does not require that kind of crap, hasn't for many many years, and only the odd driver with an idiotic installer script even asks the user to consider rebooting these days)

In fact, Windows does rather better than Linux does in this regard in that it's possible to replace the graphics driver for a running system with little more than a quick flicker.

In Linux you *still* need to restart X, which in practical terms is not much different for the desktop user than rebooting.

(I'm hoping dynamic reconfiguration is something that Wayland will improve upon, if it really gets off the ground)

Quotes of the week

Posted Dec 8, 2011 15:47 UTC (Thu) by bluss (guest, #47454) [Link] (2 responses)

Explain to me why ext3 is compiled as a module in the debian kernels.

Quotes of the week

Posted Dec 8, 2011 17:01 UTC (Thu) by nye (subscriber, #51576) [Link] (1 responses)

>Explain to me why ext3 is compiled as a module in the debian kernels

A better question would be why it's there at all, given that the ext4 driver is supposed to handle ext3 just as well (unless my understanding is wrong; that's quite possible). But it does make some sense - eg if you're using btrfs / (which I hear is all the rage these days, don'tcherknow) you likely have no need to read ext3 filesystems.

And having just looked at the result of lsmod to find out what ext? modules are loaded, I'm now wondering why I seem to have [at least] the following fs modules *all* loaded:
fuse, btrfs, ufs, qnx4, hfsplus, hfs, minix, ntfs, vfat, msdos, fat, jfs, xfs, exportfs, reiserfs, ext3, ext2, isofs, udf, ext4

Not to mention a bajillion other modules for hardware I don't have.

Quotes of the week

Posted Dec 9, 2011 10:50 UTC (Fri) by etienne (guest, #25256) [Link]

> fs modules *all* loaded: fuse, btrfs, ufs, qnx4, hfsplus, hfs, minix, ntfs, vfat, msdos, fat, jfs, xfs, exportfs, reiserfs, ext3, ext2, isofs, udf, ext4

There is probably an "automagic partition type detection" (i.e. mount -t auto /dev/... /mnt) which will modprobe all these modules, hopefully one by one, until it finds the right filesystem for that partition. Do you have an unrecognised disk partition?
That is the usual problem with automagic things, at some point the system should assume failure, and not try to detect if I have soldered a new temperature controller semiconductor chip on my motherboard since I last powered it...
It is difficult to define the limit, and still work with the widest range of hardware - for instance, is the hard disk moved to another computer a supported scenario?

Kernels may be evil

Posted Dec 9, 2011 4:45 UTC (Fri) by jd (guest, #26381) [Link] (1 responses)

BUT, until there's an autoconfig tool that scans the busses, chipsets, et al, for "default hardware" and plugs the right settings into .config, most users won't be up to it. As for distros, the only one that might even develop such a tool is Gentoo - Debian and Fedora certainly aren't going to be interested, although a "self-optimizing" version of their distros might not be a bad idea.

Kernels may be evil

Posted Jan 8, 2012 7:11 UTC (Sun) by dirtyepic (guest, #30178) [Link]

What I'd rather see is help documentation that is actually geared towards the user rather than the kernel developer and updated more than once every five years or so (if at all). Every time I read the help for "Yoyodyne KS25A1-1 Telsa Microcomp v2.1 support" and it says "Enables Yoyodyne KS25A1-1 Telsa Microcomp v2.1 support" I die a little inside.

I've always thought it would be an awesome LinuxNewbies or Gentoo Wiki project to translate things like "Enable system-call auditing support" into "Enable this if you want consolekit to work properly".

As for hardware/drivers, there is always the LKDDb (http://cateee.net/lkddb). There is also an automatic configuration script provided but I couldn't get it to work properly.