Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
The problem with leaving everything tweakable is that you're asking
users to make choices about things but not giving them the
information they need to make those choices. Whether you get a
power saving from hard drive spindown depends on whether the drive
is idle for long enough to save the power you'll spend spinning it
back up. Get it wrong and you'll be putting your drive under extra
load, reducing performance and consuming more power than you were
to begin with.
-- Matthew Garrett
If somebody wants to play with it, go wild. I didn't do
"change_bit()", because nobody sane uses that thing anyway. I
guarantee nothing. And if it breaks, nobody saw me do anything.
You can't prove this email wasn't sent by somebody who is good at
forging smtp.
-- Linus Torvalds
Look at it this way: there is no way in which the reviewer of this
patch (ie: me) can work out why this function exists. Hence there
will be no way in which future readers of this code will be able to
work out why this function exists either. This is bad. These
things should be described in code comments and in the changelog
(whichever is most appropriate).
-- Andrew Morton(Log in to post comments)
Quotes of the week Posted Jun 26, 2008 2:42 UTC (Thu) by pabs (subscriber, #43278) [Link] Awesome to see the return of the kernel quotes. I think it might be nice to have quotes in most of the other sections too.
Quotes of the week Posted Jun 26, 2008 13:08 UTC (Thu) by shapr (guest, #9077) [Link] I like to tweak my kernel, and I often have no clue of the consequences of a particular setting, even after hitting google. I do wish each kernel config had an online description where I could get links to background reading. For example, on bootup the kernel says I need to enable my IOMMU, but later in the bootup process it claims it's using my IOMMU for something. So, does my boring dual-core Athlon have an IOMMU? Is it enabled? How can I find out?
Kernel config options unexplained Posted Jun 27, 2008 15:13 UTC (Fri) by pr1268 (subscriber, #24648) [Link] The Linux Weather Forecast might help out with respect to newly-added features in recent kernels. If you are already aware of that site, then maybe I don't entirely understand what you're looking for. Yet, somewhat related to what Matthew's e-mail appears to address, and also supporting your comment, there's one kernel config option in particular that is woefully under-documented and bugs me to no end: device drivers → SCSI device support → RAID Transport Class → <Help> WTF???? (Yes, I know what a Redundant Array of Independent Disks is, in fact I have a RAID-0 in my system [properly configured in Device Drivers → Multiple devices driver support (RAID and LVM)]. But what is this kernel option doing in the SCSI driver section all by its lonesome, and what does it do, more specifically than just "Provides RAID"?)
Kernel config options unexplained Posted Jul 3, 2008 12:57 UTC (Thu) by Duncan (guest, #6647) [Link] > device drivers > SCSI device support > > RAID Transport Class > <Help> > > Provides RAID > > WTF???? That was my reaction as well, particularly since I found it, disabled, after I had my md/kernel RAID already up and functional, and was reading it on that system. If RAID wasn't provided, I'd sure like to know what I was using, then! =8^P I've still no clue on it, tho I could venture some WAGs. That's definitely an opaque config description if I ever saw one! Duncan
IOMMU, what is it? Posted Jul 3, 2008 12:52 UTC (Thu) by Duncan (guest, #6647) [Link] IOMMU == I/O (input/output) MMU (memory management unit). One big reason for them is to allow DMA I/O access to memory beyond the 4-gig barrier in 64-bit mode. Due to the I/O "memory hole" just below 4 GB, this applies to folks with 4 GB of memory (who will often have the last bit remapped above 4 GB bringing it out from behind the hole) as well. All AMD64 chipsets should all have an IOMMU (altho I'm not positive about some of the earlier non-AMD chipsets). Early em64t or whatever Intel called it did *NOT* have a hardware IOMMU -- the kernel had to "fake it" with a bounce-buffer -- in which case those "DMAs" weren't so "direct" after all. However, the same kernel config option controls the bounce-buffer on that hardware. So, if you're running 64-bit AMD64/x86_64 and have >= 4 GB memory, you DEFINITELY want the IOMMU activated. I'm not sure about 32-bit, but expect it'd be similar if somewhat more complicated to to the "hacks" necessary to access > 4 GB of memory on a 32-bit OS. The kernel config option, CONFIG_GART_IOMMU, is found under Processor type and features. On the 2.6.26-rcs, it's labeled "GART IOMMU support", tho it was labeled differently some releases back (it changed say between 2.6.16 and 2.6.22, I've forgotten). The help is actually reasonably informative, at least once you have the background on it I briefly outlined above. I don't know anything about the IBM Calgary IOMMU listed as another option, but it's apparently on IBM hardware only, according to the help. Don't get confused by it.
|
|||||||||||||