James Simmons said:
Microsoft patents loading a trusted OS into a trusted CPU. The OS prevents untrusted applications from accessing Rights Managed Data.
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.
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>/onlineUp CPU
echo 1 > /proc/sys/kernel/cpu/<id>/onlineFor 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.
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:
- 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.
USB:
include/linux/usb.h:
- Lots of documentation added. Not really an API change but you might want to know.
- HID specific defines and functions moved into include/linux/usb.h.
- FILL_BULK_URB_TO and FILL_INT_URB_TO macros removed as they were not being used.
- New inline functions usb_fill_control_urb(), usb_fill_bulk_urb() and usb_fill_int_urb() replace the FILL_*_URB macros.
drivers/usb/hid.h:
HID class defines and functions moved here.
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
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...
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.
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.
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, as well as a Linux distribution for the S390. Peter Kjellerstedt gave a link to a CRIS port as well.
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.