Kernel Traffic #148 For 31�Dec�2001

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1160 posts in 4823K.

There were 434 different contributors. 210 posted more than once. 135 posted last week too.

The top posters of the week were:

1. Microsoft Patents Loading A Trusted OS Into A Trusted CPU

12�Dec�2001�-�21�Dec�2001 (22 posts) Archive Link: "[OT] DRM OS"

Topics: Framebuffer, Legal Issues, Microsoft, Patents

People: James Simmons,�Andre Hedrick,�Alan Cox,�Dave Jones,�Aaron Lehmann,�H. Peter Anvin,�Marco Ermini

James Simmons said:

Microsoft patents loading a trusted OS into a trusted CPU. The OS prevents untrusted applications from accessing Rights Managed Data.

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2= HITOFF&p=1&u=/netahtml/search-adv.htm&r=1&f=G&l=50&d= CR99&S1=5,892,900.UREF.&OS=ref/5,892,900&RS=REF/5,892,900 (http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-adv.htm&r=1&f=G&l=50&d=CR99&S1=5,892,900.UREF.&OS=ref/5,892,900&RS=REF/5,892,900)

Andre Hedrick said:

I warned everybody the stuff was coming down the pipes. This is their method of dealing with content protection and it is going to pollute the hardware! The next thing down the pipes will be a requirement for IPC hardware encryption.

CPU(crypto)<->Memory(crypto)<->Framebuffer(crypto)
ata(clean)<->diskcontroller(crypto)<->Memory(crypto)<->CPU(crypto)
scsi(crypto)<->diskcontroller(crypto)<->Memory(crypto)<->CPU(crypto)
CPU(crypto)<->Bridge(crypto)<->Memory(crypto)

Just watch and see!

Aaron Lehmann asked why encryption would help, and Alan Cox replied:

So you cant tap the data anywhere.

Think

encrypted music fed to an encrypted audio controller to speakers which decrypt and add watermarks

encrypted video decrypted and macrovision + watermarked only in buffers the CPU cant access

audio input that has legally mandated watermark checks and wont record watermarked data.

That is the dream these people have. They'd also like the OS to scan for "illicit" material and phone the law if you do, and to have a mandatory remote shutdown of your box

(and if you read the MS media player license anyone who agrees to it signed up to that)

James bemoaned the coming of the end of the free world, and Andre said, "And it was almost a year ago when the world was exposed to this plot but everyone ignored my commentary when I was asked. The reality is, now is to late to be concerned. It is already in place. The infrastructure is laid and now it is the componet level of next generation of hardware."

Elsewhere, Aaron suggested that Linux could bypass the hardware security by reverse-engineering the behavior and implementing it in software. But Dave Jones pointed out, "Remember DMCA ? Remember SSSCA ? What you propose is classed as "Bypassing an access control"." Aaron thumbed his nose at the DMCA, saying, "I watch DVD's with DeCSS. Come and get me." He said a huge number of people bypassed the laws, and that there was no way to stop it. Dave replied:

I suggest you reread what happened to the implementor of DeCSS since you've obviously forgotten.

Whilst it's not practical for authorities to go 'get' every user of such things, there are several real world examples where they've gone after implementors, and distributors of such technology.

In a hypothetical scenario where we have sound drivers that provide ways to bypass watermarking and the likes (or even failure to implement whatever technology is deemed "necessary"), kernel.org becomes a distributor of "software to bypass access controls".

Amazing, just a few days since the Sklyarov release, and already people are forgetting this is a very real problem.

H. Peter Anvin said:

Who's forgetting? The scary part is that corporate fascism is basically the political reality in the U.S. (who is pushing very hard to export it to the rest of the world, for obvious reasons) today. Note that SSSCA failed not because of any freedom concerns, but because Microsoft and Intel didn't want the gov't to tell them what to do.

I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy.

Marco Ermini also said to Aaron, "maybe you may not get catched in the intimacy of your room. But I could understand that it's not acceptable as a legitimate proposal for a worldwide used OS, as Linux is, to suggest to every single user to violate the law in the intimacy of their room to be able to use it. I may feel safe in my own room and I may use these tools if I'm able to, but I can't propose to anyone to use these such tools, that's the point."

2. Status Of CPU Hotplugging In 2.5

13�Dec�2001�-�22�Dec�2001 (8 posts) Archive Link: "[ANNOUNCE] HotPlug CPU patch against 2.5.0"

Topics: FS: sysfs, Hot-Plugging, Power Management: ACPI

People: Kimio Suganuma,�Pavel Machek,�Dave Jones,�Arjan van de Ven,�Russell King,�Andrew Grover

Kimio Suganuma announced:

The Hotplug CPU patch for 2.5.0 is uploaded.

http://sourceforge.net/projects/lhcs/

This patch works on s390, s390x, x86 and ia64 architectures. It can also be applied against 2.4.16 with a little modification.

Down CPU
echo 0 > /proc/sys/kernel/cpu/<id>/online

Up CPU
echo 1 > /proc/sys/kernel/cpu/<id>/online

For ia64, number of CPUs to be initialized can be specified with "initcpus=<num>" option for elilo. With using the option, you can test real hot-add CPU function without a HW ready for hotplug.

Pavel Machek recommended the patch, saying, "Such patches are neccessary for ACPI S3/S4 sleep support. It would be nice to apply them soon." Andrew Grover asked for more explanation, and Pavel went on, "If you are going to S4 sleep, you should better make sure no other processors are changing stuff under your hands. Easiest way to do that is by putting them offline (I see no other good solutions). For S3 having to save state of one CPU is bad enough, having to save state of 8 would be bad, so putting them offline would be handy, too."

Elsewhere, Russell King suggested that Kimio use /proc/sys/cpu/*/ to have all CPU allocation in a consistent place. Dave Jones also explained, "The current /proc/sys/cpu/ sysctls have been added as part of Russell's cpu frequency scaling work. Currently, only the ARM specific bits are merged. There are generic bits and x86 bits waiting to be merged at some point.. The x86 part of this work uses the same framework, and was done by myself and Arjan van de Ven. It's almost in a state ready for merging also."

3. 2.5 API Change Summaries

17�Dec�2001�-�21�Dec�2001 (6 posts) Archive Link: "2.5.1 API change summary"

Topics: Big Memory Support, Disks: SCSI, FS: driverfs, SMP, USB, Virtual Memory

People: Andreas Bombe,�Randy Dunlap

Andreas Bombe said:

One problem with following kernel development is that new APIs are nowhere really summarized outside of the list thread where they are developed (if there is a thread at all). So maybe there's this great new function that simplifies something in your driver, but you don't know about it and only stumble across it much later (like 50 dev kernel revisions) and wish you'd known earlier.

So someone should just collect the changes and post a summary to linux-kernel, now wouldn't that be useful ...

[Silence, far away keyboards can be heard having "So I take it you volun..." typed on them.]

... and I will try to do that for the kernel 2.5 revisions.

I have collected the API changes in 2.5.1 and summarized below. I just read the patch for all the *.h files, so I may have confused something (like not realizing something just moved instead of being new). I also don't know much about most of the areas I'm summarizing, any corrections are welcome.

These summaries won't serve as documentation except when it's short and simple. If there are big changes, I won't list every detail (I just remind you that there is something, you can read the source yourself). I will list changes which are global or at least apply to a whole subsystem.

You'll also find stuff that's pretty much the talk of the week on linux-kernel and therefore well known, but these summaries should also serve as a overview ("when was what introduced") in combination with the kernel changelogs for those who get into 2.5 later (yes, I will archive these summaries on the web when I get a few together).

So, here it goes:

include/linux/types.h:

Typedef sector_t for block device sector numbers introduced to allow making its size an option.

include/linux/cache.h:

New macro __cacheline_aligned_in_smp that expands to __cacheline_aligned on SMP and to nothing on UP.

include/linux/kernel.h:

New macro BUG_ON(condition) which is equivalent to
if (condition) BUG();

The condition is also hinted "unlikely" to the compiler, which gives better optimization on recent gcc versions even while decreasing typing work. (And if you update your code today, we'll throw in this set of kitchen knives which will stay sharp as a razor forever...)

include/linux/genhd.h:

get_start_sect() and get_nr_sects() on kdev_t introduced.

include/linux/mempool.h (new):

Memory buffer pools introduced. "Such pools are mostly used for guaranteed, deadlock-free memory allocations during extreme VM load."

include/linux/bio.h (new):
include/linux/blkdev.h:
include/linux/fs.h:
include/linux/highmem.h:

New block IO layer introduced.

include/linux/device.h (new):
include/linux/driverfs_fs.h (new):

Centralized driver model introduced.

drivers/scsi/hosts.h:

Scsi_Host_Template and Scsi_Host include new flag highmem_io, the flag use_new_eh_code is removed along with the old error handling interface.

drivers/scsi/scsi.h:

New sg list allocation functions scsi_alloc_sgtable() and scsi_free_sgtable(). Function initialize_merge_fn() renamed to scsi_initialize_merge_fn(). Function recount_segments() removed, scsi_init_io() added.

drivers/usb/hid.h:

HID class defines and functions added.

include/linux/usb.h:

Yes, there are lots of changes. I haven't sorted them out yet.

Randy Dunlap added, "I guess you won't see summaries of proposals or actual changes in IRC discussions (: , but linux-kernel (mailing list) does have _some_ of them. For links to the ones that I'm aware of (for 2.5.x), see http://www.osdl.org/archive/rddunlap/linux-port-25x.html" .

Later, Andreas posted a revised version of his own doc:

GENERAL CHANGES:

include/linux/cache.h:

New macro __cacheline_aligned_in_smp that expands to __cacheline_aligned on SMP and to nothing on UP.

include/linux/kernel.h:

New macro BUG_ON(condition) which is equivalent to
if (condition) BUG();

The condition is also hinted "unlikely" to the compiler, which gives better optimization on recent gcc versions even while decreasing typing work. (And if you update your code today, we'll throw in this set of kitchen knives which will stay sharp as a razor forever...)

include/linux/mempool.h (new):

Memory buffer pools introduced. "Such pools are mostly used for guaranteed, deadlock-free memory allocations during extreme VM load."

include/linux/device.h (new):
include/linux/driverfs_fs.h (new):

Centralized driver model introduced. This allows all devices independent of bus to be registered in a common tree and to improve power management. See Documentation/driver-model.txt.

BLOCK DEVICES:

include/linux/types.h:

Typedef sector_t for block device sector numbers introduced to allow making its size an option.

include/linux/genhd.h:

get_start_sect() and get_nr_sects() on kdev_t introduced.

include/linux/bio.h (new):
include/linux/blkdev.h:
include/linux/fs.h:
include/linux/highmem.h:

New block IO layer introduced.

SCSI:

drivers/scsi/hosts.h:

Scsi_Host_Template and Scsi_Host include new flag highmem_io, the flag use_new_eh_code is removed along with the old error handling interface.

drivers/scsi/scsi.h:

USB:

include/linux/usb.h:

drivers/usb/hid.h:

HID class defines and functions moved here.

4. VM Subsystem Fixes In 2.4 And 2.5

19�Dec�2001�-�25�Dec�2001 (11 posts) Archive Link: "2.4.17rc2aa1"

Topics: Virtual Memory

People: Andrea Arcangeli,�Linus Torvalds,�Christoph Hellwig

Andrea Arcangeli posted a patch which "should fix the last loop deadlocks under VM pressure" . Gergely Nagy said he still saw deadlocks even with the patch, and posted some info about his hardware and the oops he saw. Meanwhile, Andrea also found another bug and posted the fix. Linus Torvalds thought that fix had already made it into 2.4, but Andrea said it hadn't yet. Linus replied, "Ok, it _is_ in 2.5.x, so I guess this was a fix that I didn't point Marcelo to well enough.." Christoph Hellwig explained, "It was a bad interaction between Marcelo and me - I send him the incomplete patch first and then the old one. It seems like he apllied the first one and I didn't check which one went in :P"

5. Status Of Asymmetric Multi-Processing

19�Dec�2001�-�20�Dec�2001 (6 posts) Archive Link: "asynchronus multiprocessing"

Topics: SMP

People: John Clemens,�Martin A. Brooks

Martin A. Brooks asked if there had been any work done on Asymmetric Multi-Processor (AMP, as opposed to SMP) support for Linux, and John Clemens replied:

I looked into this a little while ago... never got a patch working 100% correctly...there was some discussions about it on the SGI Linux Scalability list (as far as i can tell, it was the -only- discussion on the SGI list, as the IBM list started about the same time.. ahhh, orphaned mailing lists..).. It was a quick-n-dirty hack, and only the beginnings of one at that...

i put a quick page up about it at http://www.deater.net/john/processorgroups.html

Conclusion: Could be done, not worth it for miniscule speed gains, could be much more of a benefit on NUMA machines, but the linux scalable scheduler's out there are probably a much better approach to doing the same thing...

6. Compiler Optimization Requirements

19�Dec�2001�-�22�Dec�2001 (12 posts) Archive Link: "gcc 3.0.2/kernel details (-O issue)"

People: Chris Meadors,�Robert Love,�Pavel Machek,�Erik Mouw,�H. Peter Anvin

Someone noticed that changing the compiler optimization level from -O2 to -O produced a broken kernel. Chris Meadors explained, "The kernel relies on features turned on by -O2 and will not function properly with just -O of any version of gcc." But Martin Devera pointed out that 2.2 could be compiled with just -O. Robert Love confirmed Chris, statement, adding, "-O2 is the standard optimization level for the kernel; everything is compiled via it. When developers test their code, nuances that the optimization introduce are accepted. Removing the optimization may break those expectations. Thus the kernel requires it." But Pavel Machek objected, "Huh? Those expectations are *bugs*. Kernel will not link without optimalizations because it *needs* inlining. Any else dependency is a *bug*." Erik Mouw confirmed this, saying:

anything lower than -O1 simply doesn't inline functions with an "inline" attribute. The result is that the inline functions in header files won't get inlined and the compiler will complain about missing functions at link time (or module insert time).

I'm actually surprised that 2.2 can be compiled with -O, AFAIK linux-2.2 also has a lot of inline functions in headers. I know from experience that -Os works for 2.4 kernels on ARM, I haven't tested it with 2.2 or x86.

H. Peter Anvin pointed out that -O would still properly handle inlining, which would explain why the kernel could still compile.

7. 2.4 Release Policy

21�Dec�2001�-�22�Dec�2001 (21 posts) Archive Link: "Linux 2.4.17"

People: Dan Kegel,�Marcelo Tosatti,�Oliver Xymoron,�Daniel Phillips

Marcelo Tosatti announced Linux 2.4.17, and Dan Kegel was disappointed to see that this version, an official release (as opposed to pre-patches and release-candidates) was not identical to the most recent release-candidate. He said, "I'm disappointed; I thought we were entering a new era of release discipline in the stable kernel." Marcelo replied that he never said he'd keep the official releases identical to the previous release-candidate, but that "I said I would make -rc kernels which would not add any new _feature_." Daniel Phillips agreed with this, and also congratulated Marcelo on putting out the new official version. Elsewhere, Oliver Xymoron suggested that Dan's objection was not unfounded. He said, "There's always the risk of breaking something and you don't want to introduce a disk-eating bug between -rc and -final. It's better to ship one more -rc and wait a day before -final. If you don't, people will just get in the habit of waiting a day after -final to be safe."

8. Web Page Tracking All Linux Ports

23�Dec�2001�-�24�Dec�2001 (4 posts) Archive Link: "The Linux Kernel Source Finder"

Topics: Version Control

People: Dr. David Alan Gilbert

Dr. David Alan Gilbert announced:

http://www.treblig.org/Linux_kernel_source_finder.html

At this address you can find a web page where I'm trying to list the source of kernel source for all architectures and platforms. I'm currently missing a good reference for the s390 and cris architectures and some of the others are guesses on my part.

I'd be greatful for any suggestions/corrections/additions.

I intend to also add pointers to binutils/gcc/etc versions required. For those architectures which primarily use CVS I'd like to add some instructions for how to get a 'known good' set of sources (as opposed to current hackiest).

Erik Tews gave a link to IBM's S390 work (http://www10.software.ibm.com/developerworks/opensource/linux390/index.shtml) , as well as a Linux distribution for the S390 (http://linux.s390.org/) . Peter Kjellerstedt gave a link to a CRIS port (http://developer.axis.com/) as well.

9. Marcelo On Vacation

26�Dec�2001 (7 posts) Archive Link: "Vacation"

People: Marcelo Tosatti

On December 26, Marcelo Tosatti announced, "I'm going out on vacation (beach, weee) tomorrow (Thursday), and I'll return around Jan 4. Unfortunately there will be no Internet connection at the place I'll stay, sorry." Several folks wished him a happy vacation.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.