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.

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
96.06-99.09.

- linux-activists list archive
Very fragmentary, Oct 1991 to Oct 1993.
Also Oct 1993 to Jul 1995.
Also Jan 1992 to Dec 1993.

- linux-kernel
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]

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:
ftp://tsx-11.mit.edu/pub/linux/mail-archive/

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...

2.5.71 introduces two GFDL-licensed files in the kernel tree, there's a few problems with this, because:

1. COPYING in the toplevel says the kernel tree is GPLv2, GFDL is GPL incompatible.
2. Documentation/DocBook/gadget.tmpl, one of the files, includes extracted from source files licensed under GPL, making this a GPL license violation.
3. Documentation/kobject.txt, the other files claims it's under GFDL but doesn't actually include the license text as mandated by the GFDL.

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?

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.

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:

svn://kernel.bkbits.net/linux-2.4

svn://kernel.bkbits.net/linux-2.5

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

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.