Table Of Contents
|1.||8 Jun 2003 - 16 Jun 2003||(4 posts)||Support For LM78 Hardware Monitoring Chips In 2.5|
|2.||12 Jun 2003 - 13 Jun 2003||(8 posts)||Mailing List And Other Kernel Discussion Archives|
|3.||13 Jun 2003 - 16 Jun 2003||(36 posts)||Linux 2.4.21 Released|
|4.||15 Jun 2003 - 16 Jun 2003||(10 posts)||GNU "Free Documentation License" Disallowed From Kernel Sources|
|5.||15 Jun 2003 - 16 Jun 2003||(4 posts)||BitKeeper-to-Subversion Gateway|
|6.||17 Jun 2003||(5 posts)||Status Of ACPI In 2.5|
Mailing List Stats For This Week
We looked at 1463 posts in 6974K.
There were 457 different contributors. 237 posted more than once. 265 posted last week too.
The top posters of the week were:
1. Support For LM78 Hardware Monitoring Chips In 2.5
8 Jun 2003 - 16 Jun 2003 (4 posts) Archive Link: "[RFC PATCH] Add lm78 sensor chip support (2.5.70)"
Topics: FS: sysfs, Version Control
People: Mark M. Hoffman, Greg KH
Mark M. Hoffman said:
This patch vs. 2.5.70 adds support for LM78, LM78-J, and LM79 sensors chips based on lm_sensors project CVS. This works on one of my boards.
I want to draw attention to something I did with this driver by comparing it to it87.c in 2.5.70:
> #define IT87_INIT_TEMP_HIGH_1 600
> #define IT87_INIT_TEMP_LOW_1 200
The hardware uses degrees C, and sysfs uses degrees C * 1000. But these #defines are apparently in units of degrees C * 10. This arbitrary intermediate representation bugs me. And given the new 2.5 sysfs standard, it's unnecessary.
In this patch for lm78, I rewrote the conversion routines in terms of the sysfs units - getting rid of the intermediate nonsense. If there are no objections, I'm going to start passing patches to do this to the other sensor chip drivers in 2.5 as well. It would be nice to get some help with this too... especially since I don't have all that hardware at hand to test the results.
Greg KH asked if Mark wanted this included in the main tree, and Mark replied, "I was hoping to get some feedback w.r.t. the conversion routines... but I guess silence is consent. Please pass this on in the next round." So a few days later Greg applied it, and the thread ended.
2. Mailing List And Other Kernel Discussion Archives
12 Jun 2003 - 13 Jun 2003 (8 posts) Archive Link: "Anybody gotta list archive tarball?"
People: Jonathan Corbet, Andries Brouwer, Rob Landley, Hal Duston
Jonathan Corbet asked, "Does anybody happen to have (and is willing to share) a tarball containing archives of this list going back well into the 90's? I am, shall we say, researching the activities of certain companies (when I should really be working on driver books) and something greppable would be most helpful." Andries Brouwer replied:
I tend to collect such things, but lost early stuff in disk crashes. There is here
- stuff from ftp://ftp.uwsg.iu.edu/linux/mail.archive/kernel/
1 Mar 1996 - now.
[you can ftp that yourself, I suppose]
- stuff from linuxwww.db.erau.edu
- linux-activists list archive
Very fragmentary, Oct 1991 to Oct 1993.
Also Oct 1993 to Jul 1995.
Also Jan 1992 to Dec 1993.
Jul 1995 to Apr 1996.
[lots of garbage in various different formats and from various sources; very time consuming to sort out; different archives are very similar but do not have precisely the same posts; I can make the raw stuff available if you want - maybe you don't want]
Rob Landley also remarked, "the oldest linux list archive I know of is the one the kansas city people have. http://www.kclug.org/old_archives/linux-activists/"
Elsewhere, under the Subject: linux-activist archives (http://www.uwsg.indiana.edu/hypermail/linux/kernel/0306.1/1619.html) , Hal Duston said:
I am the webmaster for kclug.org, and can tar up the stuff I've created if you like. I grabbed the archives from other publicly available locations several years ago. I would assume you would rather have the originals instead of my hackish processing of them. I do still have them as well if the sites I obtained them from aren't available anymore.
Here is one of my sources:
Looks like my other source has been moved there as well.
Thanks. linux-activists, I think, predates the era I'm trying to research now. I'd like to snarf it at some point and put together the ultimate archive, but that comes later.
For now, I've managed to get the linux-kernel archives for the last 8 years or so, thanks to responses to my original message - thanks. I've gotten a little distracted now that SCO has fingered RCU as one of its areas of concern...I think enough has been dug up now that they won't get much further with *that* argument. Time for some more general trolling...
3. Linux 2.4.21 Released
13 Jun 2003 - 16 Jun 2003 (36 posts) Archive Link: "linux-2.4.21 released"
Topics: FS: XFS, Power Management: ACPI, Real-Time
People: Christoph Hellwig, Marcelo Tosatti, Robert Love
Marcelo Tosatti released 2.4.21 (http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.21) , with no changes from the 2.4.21-rc8 release. A lot of folks were disappointed that ACPI had not been updated to include the latest patches. Someone also suggested including XFS, and Christoph Hellwig replied, "I'll start feeding the few remaining core changes to Marcelo now, the actual filesystem then is just yet another driver that could be merged any time :)" Other folks suggested the preemption patches; but Robert Love said these were too invasive for the stable series at that point, although they were going into 2.5.
4. GNU "Free Documentation License" Disallowed From Kernel Sources
15 Jun 2003 - 16 Jun 2003 (10 posts) Archive Link: "GFDL in the kernel tree"
People: Christoph Hellwig, Linus Torvalds
Christoph Hellwig reported:
2.5.71 introduces two GFDL-licensed files in the kernel tree, there's a few problems with this, because:
And of course there's still all those nasty issue with GFDL like invariant sections and cover texts that make at least the debian-devel list believe it's an unfree license..
Folks, could we please only use GPL-compatible licenses in the kernel tree?
Linus Torvalds replied:
I'd agree. The GFDL is a disaster anyway. You can't even fix bugs in the documentation without having to change the title etc. There are much better licenses around.
I'd say we just remove the files.
5. BitKeeper-to-Subversion Gateway
15 Jun 2003 - 16 Jun 2003 (4 posts) Archive Link: "bkSVN live"
Topics: Version Control
People: Ben Collins, Geert Uytterhoeven
Ben Collins announced:
Thanks to Larry, the bkSVN repo is now live. It's actually bkcvs2svn, since I am using bkcvs's metadata. However subversion is able to make better use of the metadata than CVS can. You can get better log output, for one. Also, you can more easily determine the scope of a change, since subversion supports changesets.
If you aren't familiar with subversion, please visit the URL in my sig. Please do not ask me a lot of questions about it. First off, it's very well documented, and second off, I am not what I would consider an expert on the internals of SVN.
And please DO NOT email linux-kernel with any comments, suggestions, questions regarding subversion. It is way off topic. Subversion != BitKeeper, and it's not intended to replace it. So this isn't a competition. Otherwise, Larry wouldn't feel so comfortable with hosting the repo :)
For those that know SVN, you need a recent (e.g. upcoming 0.24 release of SVN, or current trunk) client. I am using revision r6227. If you need a client just for testing, you can get a ra_svn only static binary from http://www.phunnypharm.org/pub/svn/clients/linux/. i386, sparc and ia64 are there. I can build more if needed (I think I have access to just about anything). You'll need glibc 2.3 for the static clients since it uses NSS modules, and well, it just wont work with 2.2/2.1/etc. If you want to build your own, remember, you don't need berkeley DB, or neon to access this repo.
Now, finally the SVN URL's:
WAIT. If you don't know anything about SVN repo layouts, just remember this:
REPO_BASE/trunk Primary (aka HEAD) development REPO_BASE/tags/* Tagged revsions REPO_BASE/branches/* Other development lines (not used in bkSVN)
So, to get the main development for say 2.5:
# svn co svn://kernel.bkbits.net/linux-2.5/trunk linux-2.5-bkbits
Will checkout the main 2.5 trunk into a directory called linux-2.5-bkbits. Then you can cd into that directory and do "svn up" just like CVS :). The "svn log" output is much better than in CVS, since you can do things like "svn log drivers/usb" and get a single list of revisions that affected anything in drivers/usb, unlike CVS where you would get history for all files seperately. "svn help" is really useful aswell.
If you want to checkout a particular version:
# svn co svn://kernel.bkbits.net/linux-2.5/tags/v2.5.60 linux-2.5.60
Or diff versions, via URL, without a working copy:
# svn diff svn://kernel.bkbits.net/linux-2.4/tags/v2.4.19 svn://kernel.bkbits.net/linux-2.4/tags/v2.4.20 > patch-2.4.20.diff
Geert Uytterhoeven tried with an earlier version and got "svn: Malformed network data" errors, and asked, "Can you confirm that 0.23.0 (r5962) (from Debian unstable) is too old, or is this a PPC-specific problem?" Ben replied, "Too old. 0.24 will release with some incompatible revamps to the ra_svn protocol, but it improves checkout over high latency by a noticable amount."
6. Status Of ACPI In 2.5
17 Jun 2003 (5 posts) Archive Link: "ACPI broken... again!"
Topics: Microsoft, Power Management: ACPI, USB
People: Felix von Leitner, Andrew Grover
Felix von Leitner was unable to get ACPI working under kernel 2.5.70, on any of the five machines he tried it on. He said:
The symptom is that eth0 does not see the others. /proc/interrupts has the correct interrupt listed, so it took me a while to suspect ACPI. agpgart also crashes, and firewire and USB didn't find any devices.
Why oh why is ACPI so horrendously broken?
And more to the point: if it _is_ this broken, why ship it at all? I don't recall a single moment where ACPI did anything good for me, only crashes, data loss and general brokenness. This may be a technology fitting Microsoft and Intel PCs, but why give it even more leverage by supporting it in Linux? I say rip this abomination right out of the kernel and be done with it.
Someone explained why it was so hard to get ACPI right, saying, "its a moderately bad spec that your vendor implemented to deal with a horrid redmond interpreter. (And, to make things worse, the linux-acpi team specifically insists on implementing the spec, not the reality. "We refuse to be bug-for-bug compatible with the other major implementation." So linux-acpi is "right" but redmond-acpi is tested and actually works.)"
Several other folks asked Felix for more information about his hardware, and Andrew Grover came down on him for complaining instead of working to fix the problems.
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.