Kernel Traffic #255 by Zack Brown
[email protected] Wed, 31 Mar 2004 15:08:53 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #255 For 31 Mar 2003
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 15 Feb - 19 Feb (8 Strace Test Tool Released
posts)
2. 16 Feb - 20 Feb (5 Using Sounds Cards For Generic Data Transfers
posts)
3. 17 Feb - 25 Feb (14 Virtual Ethernet Driver For IBM iSeries And
posts) pSeries
4. 17 Feb - 26 Feb (99 Intel Vs. AMD x86-64
posts)
5. 17 Feb - 22 Feb (22 Linux 2.6.3 Released
posts)
6. 17 Feb - 22 Feb (10 Linux 2.4.25-rc4 Released
posts)
7. 17 Feb - 21 Feb (22 Linux 2.6.3-mm1 Released
posts)
8. 18 Feb - 19 Feb (4 UFS2 (And UFS1) Read-Only Patch
posts)
9. 18 Feb - 25 Feb (5 Sensor Chips SysFS Interface Change
posts)
10. 18 Feb - 22 Feb (9 Status Of 2.0 Port Of uClinux
posts)
11. 19 Feb - 20 Feb (9 Hot-Swapping Linux Kernels
posts)
12. 19 Feb - 23 Feb (26 udev 018 Released; Starting To Be Fully
posts) Usable; Some udev Docs
13. 20 Feb (4 Linux 2.6.3-mm2 Released
posts)
14. 20 Feb - 23 Feb (17 device-mapper Updates
posts)
15. 20 Feb - 23 Feb (3 Linux Stability Page Updated
posts)
16. 20 Feb (2 iswraid Update For 2.4
posts)
17. 22 Feb - 26 Feb (37 List Of fbdev Issues
posts)
18. 23 Feb - 25 Feb (14 Bluetooth SysFS Support
posts)
19. 23 Feb - 26 Feb (6 Status Of ATI IXP150 Southbridge Support
posts)
20. 24 Feb (1 Libsysfs v1.0.0 Released
post)
21. 25 Feb (5 New Teletex Decoder SAA5246A Driver
posts)
22. 25 Feb (1 Reiser4 Snapshot Against 2.6.3
post)
23. 25 Feb - 26 Feb (7 Linux 2.4.26-pre1 Released
posts)
24. 25 Feb (1 BitMover Openlogging Server Moved
post)
25. 27 Feb - 1 Mar (6 Linux 2.6.4-rc1 Released
posts)
26. 28 Feb (1 BitMover Updates openlogging.org Server
post)
27. 28 Feb - 2 Mar (41 Status Of pmdisk; Removal Considered
posts)
28. 29 Feb - 1 Mar (9 FUSE Filstystem Interaction With SELinux
posts)
29. 29 Feb - 2 Mar (22 Linux 2.6.4-rc1-mm1 Released
posts)
30. 3 Mar (6 Developers Plan kgdb Patch Submission
posts)
Mailing List Stats For This Week
We looked at 4058 posts in 19657K.
There were 936 different contributors. 456 posted more than once. 272 posted
last week too.
The top posters of the week were:
* 134 posts in 539K by Andrew Morton
* 116 posts in 525K by Greg KH
* 108 posts in 399K by Linus Torvalds
* 75 posts in 286K by Benjamin Herrenschmidt
* 73 posts in 270K by Jamie Lokier
* Full Stats
1. Strace Test Tool Released
15 Feb - 19 Feb (8 posts) Archive Link: "[Announce] Strace Test"
People: Dan Carpenter, David Weinehall, Anton Blanchard, Robert Williamson
Dan Carpenter said:
I'm happy to announce the initial public release of Strace Test. I believe
Strace Test is the most aggressive general purpose kernel tester available.
Strace Test generally crashes my system within 5 minutes (2.6.1-rc2).
Strace Test uses a modified version of strace 4.5.1. Instead of printing
out information about system calls, the modified version calls the syscalls
with improper values. A patch and a binary for i386 are included in the
strace_test tar ball.
Strace Test uses LTP to generate real world syscalls. Just unpack ltp and
type 'make -k'. You don't need to install the test if you don't want to.
The modifications make the test scripts go haywire. To keep the test on
track we restart it every 10 seconds. The first script is run as root and
it spawns off the test as a test user. Every 10 seconds root kills off all
the test user's processes and restarts the test. The actual tests are run
with user permissions.
Strace Test is available from: http://67.113.20.209/strace_test.tar.bz2
Test Instructions (for i386)
Create a test user
Download and untar ltp (ltp.sf.net)
Cd to ltp and `make -k`
Untar strace_test
cd strace_test && ./go_go.sh
Enter the path to ltp
Enter the test user
Anton Blanchard and Robert Williamson were extremely impressed by this, and
David Weinehall also asked, "Pretty please with sprinkles upon, could you
stress test a 2.0.40 kernel and report your results to me? While I do not
expect the 2.0-kernel to be the paramount of stability, it would be nice to fix
any obvious bugs..."
2. Using Sounds Cards For Generic Data Transfers
16 Feb - 20 Feb (5 posts) Archive Link: "transferring data through the sound
card"
Topics: Modems, Networking, Sound
People: Jamie Lokier, Paulo Marques, Pavel Machek, Michael Clark
Nischal Saxena asked if it were possible to transfer data between two systems,
via the sound cards. Jamie Lokier siad, "It's possible using a software modem,
but it's much easier to use a network card instead :)" Paulo Marques replied:
Since Nischal didn't specify which port on the sound card he was thinking
about, I started to think that a SPDIF digital output / input, would give
much better results:
6 channels, 16 bit, 48KHz = 4.6Mbit/s
I don't know enough about the standard digital format and the maximum
bandwidth that we could get from a sound card, but in theory we probably
could connect the digital input on a sound card to digital output on
another card (and vice-versa) and map the whole thing as a network
interface :)
Anyway, this is an extremely crazy, time wasting, "just do it if you have
loads of time to throw out the window" kind of project, because the cost of
ethernet NIC's is extremely low these days.
Elsewhere, Pavel Machek remarked, "I was able to transfer data using dtmf and
dtmf decoder (PC beeper to internal microphone of notebook), but with advanced
software much better speed should be possible." Michael Clark replied, "I
believe it's already being worked on (as a subset of what the GNU radio project
is doing - software modulation/demodulation - just removing the requirement for
down conversion): http://www.gnu.org/software/gnuradio/gnuradio.html"
3. Virtual Ethernet Driver For IBM iSeries And pSeries
17 Feb - 25 Feb (14 posts) Archive Link: "[PATCH][2.6] IBM PowerPC Virtual
Ethernet Driver"
Topics: Networking
People: Santiago Leon, Jeff Garzik
Santiago Leon said:
Here's a patch that adds the inter-partition Virtual Ethernet driver for
newer IBM iSeries and pSeries systems:
The patch applies against 2.6.3-rc3...
Jeff, can you formally add this driver to 2.6?... The differences between
this driver and the 2.4 driver that you accepted are fairly trivial (i.e.
workqueues instead of tasklets)... The architectural additions that I was
waiting for have been applied to the mainline tree...
Jeff Garzik accepted the patch; and various folks discussed its technical
merits.
4. Intel Vs. AMD x86-64
17 Feb - 26 Feb (99 posts) Archive Link: "Intel vs AMD x86-64"
Topics: Assembly, Hyperthreading, Patents
People: Linus Torvalds, Mikael Pettersson, Diego Calleja Garcia, Bryan
O'Sullivan, Aaron Lehmann, Herbert Poetzl, Vojtech Pavlik, Jun Nakajima, Adrian
Bunk, Pavel Machek
Linus Torvalds said:
now that Intel has finally come clean about their x86-64 implementation
(see http://www.intel.com/technology/64bitextensions/index.htm?iid=
techtrends+spotlight_64bit for full details), can somebody write up a list
of differences? I know there are people who have had access to the Intel
docs for a while now, and obviously Intel is too frigging proud to list the
differences explicitly.
From what I can tell from a quick look, it looks like it is basically just
the 3DNow vs SSE3 thing, but I assume there are other details too. Can
people who have been involved with this make a quick list for the rest of
us who only got to see the final details today?
(And I assume there's somebody with a few patches pending..)
Mikael Pettersson said:
From what I can see from these docs, Intel's "IA-32e" is very very close to
the natural combination of P4 with AMD64. No hyperlink stuff, but otherwise
the same. The local APIC and performance counters should be exactly as in
P4 :-)
What about naming? IA-64 is taken, AMD64 is too specific, Intel's "IA-32e"
sounds too vague, and I find x86-64 / x86_64 difficult to type. "x64"
perhaps?
Diego Calleja Garcia asked, "Does that mean that the opteron-based distros will
be able to run their x86-64 kernelspace/userspace in intel micros without
modifications, or only the userspace?" And Bryan O'Sullivan replied,
"Presumably there will be some minor kernel modifications needed, but Intel's
public position is that going forward, there's only one 64-bit kernel and
userspace needed for both platforms."
Elsewhere, regarding naming, Aaron Lehmann suggested, "I feel that AMD64 is
appropriate. We've been calling all the AMD/Cyrix chips IA32 processors, and
this is no different." But Mikael replied, "Actually I would call them x86,
never IA32."
Elsewhere, Linus said:
x86-64 it is. Maybe you can remap one of your function keys to send the
sequence ;)
This whole "ia32" crap has always been ridiculous - nobody has _ever_
called an x86 anything but x86, and Intel is just making it worse by adding
random illogical letters to the end.
In contrast, x86-64 tells you _exactly_ what it's all about, and is what
the kernel has always called the architecture anyway.
Herbert Poetzl asked, "so the current x86_64 will be changed to x86-64 or will
there be x86_64 and x86-64? probably I missed something important, but AMD64
seems to be labeled x86_64 in 2.4 and 2.6" Linus replied:
No. The filesystem policy _tends_ to be that dashes and spaces are turned
into underscores when used as filenames. Don't ask me why (well, the space
part is obvious, since real spaces tend to be a pain to use on the command
line, but don't ask me why people tend to conver a dash to an underscore).
So the real name is (and has always been, as far as I can tell) x86-64.
Actually, I'm a bit disgusted at Intel for not even _mentioning_ AMD in
their documentation or their releases, so I'd almost be inclined to rename
the thing as "AMD64" just to give credit where credit is due. However, it's
just not worth the pain and confusion.
Any Intel people on this list: tell your managers to be f*cking ashamed of
themselves. Just because Intel didn't care about their customers and has
been playing with some other 64-bit architecture that nobody wanted to use
is no excuse for not giving credit to AMD for what they did with x86-64.
(I'm really happy Intel finally got with the program, but it's pretty petty
to not even mention AMD in the documentation and try to make it look like
it was all their idea).
Vojtech Pavlik remarked:
As far as I know, the real reason for the underscore in x86_64 in Linux is
that autoconf/configure hate dashes in arch names, because of this
notation:
x86_64-gnu-linux-pc
If a dash were used, the string would be unparseable without prior
knowledge of all arch names.
Elsewhere, Adrian Bunk suggested using 'AMD64' as the name, since that was what
was used in SuSE, RedHat, and Debian, but Linus replied:
Well, the thing is, I _like_ a vendor-neutral name.
I think it's important to have multiple sources for a chip, and I think one
of the problems with IA-64 was that it was a locked-in chip with patents
and no serious competition internally (ignore the Intel mouthing about
"open").
The x86 is so great partly because there's been real competition. So I
think it's very important to x86-64 to have real competition to make sure
nobody gets too dishonest.
So AMD64 is a bad name, partly for the same reason IA32 is a horrible name
(and who have you ever heard use the IA32 name except for people who are
paid to do so by Intel?)
What I found so irritating is that _hours_ after the Intel announcement,
people were _still_ confused about whether the new intel chip was actually
compatible with AMD's chips. Why the f*ck not just come out and say so, and
talk about it? It took people actually reading the manuals (which didn't
mention it either) to convince some people on the architecture newsgroups
that yes, "ia32e" was really the same as "amd64" except in the small
details that have always set Intel and AMD apart.
So I don't really want to change the name. "x86-64" is a good name. I just
wish there was more honesty involved, and less friggin *POSTURING*.
Jun Nakajima from Intel replied:
Sorry for the miscommunication. The page http://www.intel.com/technology/
64bitextensions/faq.htm says at the _bottom_ at least:
Q9: Is it possible to write software that will run on Intel's
processors with 64-bit extension technology, and AMD's 64-bit capable
processors?
A9: With both companies designing entirely different architectures, the
question is whether the operating system and software ported to each
processor will run on the other processor, and the answer is yes in
most cases.
Pavel Machek asked for a list of differences between amd64 and ia32e, and Jun
replied:
Other than the standard IA-32 differences (eg. HT, SSE3, Intel Enhanced
SpeedStep, etc.), there are few differences between the implementations of
IA-32e and AMD64. The software visible ones are:
Fast system calls:
Syscall/sysret is supported only in 64-bit mode (not in compatibility
mode). Sysenter/Sysexit is supported in both 64-bit and compatible
mode.
CPUID:
If you look at Table 2-8 of Volume 1, you will find IA-32e specific
things, including, GenuineIntel, HT, SSE3, monitor/mwait, Intel
Enhanced SpeedStep, and cmpxchg16b.
The function 8000_0001h doesn't duplicate standard-feature bits from
function 1 in EDX. It sets only the new features that are implemented.
MSRs:
Not all MSRs are architectural, and IA-32e does not implement SYSCFG,
TOP_MEM, TOP_MEM2, for example. MSR usage should be vendor specific and
be guarded with CPUID.Model
Fast-FXSAVE/FXRSTOR:
IA-32e always saves all of the FP state on FXSAVE/FXRSTOR. Does not
support FXSAVE/FXRSTOR with reduced FP state.
Microcode Update:
IA-32e supports microcode update as the 32-bit mode does, as you
already found the discussions in the mailing list.
NX (No-Execute) bit:
Initial implementation will not support the NX bit.
BSF/BSR when source is 0 & operand size is 32:
In 64-bit mode, the processor sets ZF, and the upper 32 bits of the
destination are undefined. Should always check the ZF or do not use
32-bit operand size.
Near branch with 66H prefix:
As documented in PRM the behavior is implementation specific and should
avoid using 66H prefix on near branches.
Not supported in IA-32e
3DNow instructions (including prefecthw or prefetch with the opcode 0f
0d)
5. Linux 2.6.3 Released
17 Feb - 22 Feb (22 posts) Archive Link: "Linux 2.6.3"
People: Linus Torvalds
Linus Torvalds announced Linux 2.6.3, saying:
Ok, it's out.
There were some minimal changes relative to the last -rc4, mostly some
configuration and build fixes, but a few important one-liners too.
6. Linux 2.4.25-rc4 Released
17 Feb - 22 Feb (10 posts) Archive Link: "Linux 2.4.25-rc4"
Topics: Power Management: ACPI
People: Marcelo Tosatti, Willy Tarreau, Pavel Machek, Hilko Bengen
Marcelo Tosatti announced:
Here goes release candidate 4, including a few small fixes.
If nothing bad shows up, this will become final.
Willy Tarreau replied, "I would have liked to see the ACPI poweroff fix I sent
a few days ago, but Len said he doesn't have time to review it this week. It's
a shame since at least two of my machines which powered off correctly with very
older ACPI versions now need it, so I don't think I'm the only one in this case
:-(" Marcelo took a look at the fix, and said it looked OK and would probably
get into 2.4.26-pre1. Willy was happy about this, and Pavel Machek remarked, "I
bet it will create "machine will reboot instead of poweroff" on some strange
machine.... Perhaps it fixes more machines than it breaks, but it will probably
break some." Willy asked if Pavel had a clearer idea of what would break, but
Pavel said simply, "No, but this is ACPI. No matter how simple change looks, it
will break something."
Elsewhere, Hilko Bengen asked why his I-Surf patch hadn't been included in
2.4.25-rc4. He said, "Ok, the bug has been there for ages and, being an ISA
card, the I-Surf is probably not used that much any more... Was there anything
wrong with the patch I sent?" Marcelo said he thought the patch looked fine,
and would probably be in 2.4.26-pre1. Hilko was pleased with this, and offered
another small patch in the same area.
7. Linux 2.6.3-mm1 Released
17 Feb - 21 Feb (22 posts) Archive Link: "2.6.3-mm1"
Topics: Big Memory Support, FS: ext3, Framebuffer
People: Andrew Morton, Andi Kleen, Joe Thornber, Bill Davidsen, Brandon Low
Andrew Morton announced 2.6.3-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3/
2.6.3-mm1/
+ Added the dm-crypt driver: a crypto layer for device-mapper.
People need to test and use this please. There is documentation at
http://www.saout.de/misc/dm-crypt/.
We should get this tested and merged up. We can then remove the nasty
bio remapping code from the loop driver. This will remove the current
ordering guarantees which the loop driver provides for journalled
filesystems. ie: ext3 on cryptoloop will no longer be crash-proof.
After that we should remove cryptoloop altogether.
It's a bit late but cyptoloop hasn't been there for long anyway and it
doesn't even work right with highmem systems (that part is fixed in
-mm).
+ Added the fbdev cursor API patch. Not sure what this does apart from
preventing the rivafb driver from linking. I'll let others decide if
this is progress.
+ There's a patch here to consolidate the 32->64 compat code for the IPC
syscalls. Needs testing on various 64-bit machines.
+ Various random fixes to things.
Andi Kleen said, "While 2.3 and 2.4 have broken the on disk format of crypto
loop several times (each time to a new "improved and ultimately perfect
format") I don't think that's acceptable for a mature OS anymore." He asked,
"Is it guaranteed that this thing will be disk format compatible to cryptoloop?
" Andrew replied, "Allegedly. Of course, doing this will simply retain
crypto-loop's security weaknesses." Andi replied:
AFAIK the two big security weaknesses in most version of cryptoloop are:
(note that some versions have it fixed with various hacks)
+ Weak IV
+ Extremly bad key management
The first can be addressed in an crypto API module e.g. with an hashed IV,
but it needs a stable IV format from dm-crypto (that is one of the things I
asked for)
The second one is more a user space problem. However to solve it you need
metadata. It would be much nicer if it was possible to store it on the
block device directly (with a special losetup flag for compatibility).
Otherwise you get into nasty chicken and egg problems with fully encrypted
systems.
Supporting metadata can be quite simple - e.g. a standard header on the
first blocks that has a length and a number of records with unique IDs. And
the kernel driver would need to skip over these headers.
Joe Thornber pointed out, "The target already takes an offset into the device,
so you have what you want." Andi replied, "Ok fine. The only requirement would
be compatible IVs then." Andrew wanted some clarification, asking, "Would it be
correct to say that until someone does this development, dm-crypt has the same
vulnerabilities as cryptoloop? Or is there some different way of using dm-crypt
which is incompatible with cryptoloop, but is more secure?" Andi replied, "It
all depends on what the crypto API module and the user space utils implement.
That is why calling it dm-crypt is misleading, dm-filter or somesuch would be
better." But he added that anything more secure than cryptoloop would have to
be incompatible with it.
Completely elsewhere, Bill Davidsen objected to removing cryptoloop, saying:
What definition of "stable kernel" do you use which includes removal of
features which were reasons to migrate to 2.6 from 2.4? This change would
mean having to add dm to the kernel which otherwise doesn't use it, carry
dm utilities on the system whcih are otherwise unneeded, and train people
to use and not use dm.
I expect major things to change in a development series, but less major
things than this have been pushed to 2.7, why is this being forced in?
Brandon Low seconded this objection, but Andrew was unimpressed by either. He
said:
Why should we retain crypto capabilities which have widely understood
vulnerabilities?
We mainly want to remove the bio remapping stuff from the loop driver
because it's horrid and deadlocks under heavy memory pressure. Maybe we can
leave crytoloop there with big "kindergarten crypto - do not use" labels
all over it.
Brandon replied:
the point is that the new dmcrypto is only in -mm and cryptoloop is in both
trees, those of us developing applications based on cryptoloop don't have a
mainline kernel to even start testing dmcrypto against in the 2.6 series,
so it is more a political issue than a technical issue which makes the
removal of a feature like this from the 2.6 series a bad thing... (In my
humble never contributed to the kernel opinion)
Technically speaking there is no doubt that you are correct to want to
remove cryptoloop... but if people are depending on that support to stay in
a stable kernel and are developing based on it and don't have the time to
learn dm or dmcrypto and redesign whatever may need redesigning to use it,
it strikes me as rude to pull that support.
But Andrew came back with:
This is actually an argument for removing cryptolooop. People are
developing against a crypto infrastructure which has well-known weaknesses.
Pulling it out is an excellent way of communicating this fact. Right now,
we're just deluding people.
Brandon had to admit that Andrew had a point, though he was still unhappy about
it.
8. UFS2 (And UFS1) Read-Only Patch
18 Feb - 19 Feb (4 posts) Archive Link: "[PATCH] [2.6] UFS2 Read Only Patch"
Topics: BSD: FreeBSD
People: Niraj Kumar, Andrew Morton
Niraj Kumar said to Andrew Morton:
Please apply this patch . They provide the bare minimum read-only support
for ufs2 variant (from FreeBSD 5.x ) of the UFS filesystem .
The patch for 2.6.3 is here :
http://ufs-linux.sourceforge.net/ufs2/2.6.3/ufs2-read-only-p1.txt
http://ufs-linux.sourceforge.net/ufs2/2.6.3/ufs2-read-only-p2.txt
Andrew replied:
ooh, I see you have a mkfs.ufs there. Does it support UFS1 as well?
Does current UFS support little-endian machines? If so, has this code been
tested on a little-endian host? The code _looks_ OK, but one does need to
test...
Has the patched filesystem been regression tested against a UFS1
filesystem?
Niraj confirmed that his patch did indeed support UFS1. He added that
regression testing had been minimal, "Only some most basic (mount , read )
functionality" .
Andrew also had severe issues with Niraj's coding style, and Niraj posted an
updated patch.
9. Sensor Chips SysFS Interface Change
18 Feb - 25 Feb (5 posts) Archive Link: "[RFC 2.6] sensor chips sysfs
interface change (long)"
Topics: FS: procfs, FS: sysfs
People: Jean Delvare, Pavel Machek, Greg KH
Jean Delvare said:
I plan to make rather important changes to the sysfs interface of I2C chip
drivers in Linux 2.6. The topic has already been discussed on the
lm_sensors mailing list, bug Greg KH suggested that I should explain my
intentions here too, so here I am.
THE PROBLEM
The sysfs interface to I2C chips as it exists in Linux 2.6 isn't that bad.
It has a number of benefits over the old procfs interface we used during
the times of 2.2 and 2.4 kernels. The main change (apart from the
pseudo-filesystem change itself) is that we opted for a one-value-per-file
policy, with the obvious goal to make this interface more chip-independent.
We also decided that all values, which are mainly fixed point values, would
all use the same number of decimal places, again to make it less
chip-dependent.
A few changes were made recently to enhance the chip-independency, such as
differentiating between minimum temperatures and hysteresis temperatures.
The problem is that there are still several files that need you to know
additional information about the chip to properly use them. Examples of
that:
+ Hysteresis temperature values can apply to several limits. For most
chips it applies to the max temperature, but for some it applies to the
critical temperature. One chip (LM80) even has the two of them, so its
sysfs interface doesn't comply with the defined standard.
+ Alarms are represented as bit vectors. The meaning of each bit is
chipset-dependent.
There is a second, less important problem. The file naming scheme was not
chosen in accordance with what was done in previous kernels and libsensors,
the sensors information access library. When we would refer to "temp1_max"
before, the corresponding sysfs file is now "temp_max1". I say it is less
important because it doesn't affect the chip-independency of the current
interface. Still it requires additional code in libsensors (not much,
admittedly), makes "ls" group the sysfs files in an irrelevant order, and
is likely to make sysfs the future interface "discovery" code a bit more
complex.
THE REASONS FOR CHANGE
Although the problem detailed above probably makes it clear why I want to
alter the sysfs interface, I think some of you will be interested in more
details on why I want them to occur, and more specifically why I want the
changes to be made as soon as possible, although in a stable series.
My ultimate goal is to make it possible to write a completely
chip-independent sensors library. The way things were done so far, adding
support for a new hardware monitoring chip always requires to update the
library and user-space programs (such as "sensors"). At the moment, 75% of
the libsensors code is chipset specific, and almost 90% of the "sensors"
user-space tool code is. This demonstrates how much code we could save,
would we have a truly chip-independant sysfs interface. This also means
that the library and user-space tools wouldn't have to be updated with each
new chip driver (with the exception of the sensors.conf configuration
file).
Since only 30% of the sensors chip drivers have been ported to Linux 2.6
yet, I think that if we are to change the interface, we better do it before
porting the other 70% (well, obviously less since some of them will
probably never be ported).
Also, were we to wait for Linux 2.7 before starting these changes, as some
of you might suggest, this would mean that the new sensors library would be
either usable only there (which basically means maybe 3 years or so before
a monitoring application can rely on this library only), or it would have
to support both the 2.6 and 2.7 sysfs standards. This is likely to make the
code be much more complex, for basically no benefit.
In fact, I don't feel bad to change the standard now because it is hardly
established yet. It isn't as if I were planing to change a long-established
standard. With each new Linux 2.6 release since .0, we have been updating
the standard and modified the drivers to comply with it, so that we had to
release a new libsensors each time. One more change won't hurt much more,
especially if this is this ensures this is the last one. I also insist on
the fact that, since the sysfs interface is not chip-independent yet,
applications are discouraged to access the sysfs interface directly, and
should rely on libsensors instead. Since we keep the library in sync with
the Linux 2.6 kernel (and will continue to do so), such applications are
not affected by the changes (except that libsensors has to be updated),
even the relatively important one I propose to make here.
THE PLAN
I propose a three-step plan.
1. Change the base scheme (e.g. temp_min1 -> temp1_min). This is the more
important change (in the sense it affects all drivers and the
libsensors library) and correspond to the second problem listed above.
Benefits of the new naming scheme are:
o Back to the original (libsensors) names, more natural to the
sensors developers. Allows some simplifications in the current
libsensors. Represents the relations between the different values
in a more understandable way IMHO. References in the sensors.conf
configuration file will match the file names.
o Better ordering by "ls" and the such. Groups name by sensor instead
of limits.
o Probably easier "browsing" code later. For example, if you want to
treat all files related to the first temperature sensor, looking
for files beginning with "temp1_" should be easier than looking for
files beginning with "temp_" and ending with "1" not preceeded by
another digit. Likewise, getting the sub-item is easy in the
"temp1_min" scheme (access string+strlen(prefix)) and you're done)
while it looks more tricky with the "temp_min1" scheme. Of course,
all this depends on how you will be handling the whole thing in
your application, and which language you use, but to make it short,
it really looks like the "temp1_min" scheme can be handled with
basic C functions while the "temp_min1" scheme would be more easily
handled with regular expressions.
2. Change the hysteresis names (temp1_hyst -> temp1_max_hyst). Only some
drivers are impacted. Changes required to the library as well.
Benefits:
Increase the chip-independency by making it clear which limits the
hysteresis do apply to. The lm80 driver *needs* this since it has two
hysteresis values per temperature channel.
3. Add splitted alarm files. This doesn't break the interface (these are
new files), but on the other hand needs that we think about it a bit
more so that our choices are extendable and correct for all known
drivers.
I would like to make steps 1 and 2 occur as soon as in Linux 2.6.4 (i.e.
immediately), because they break the interface. Step 3 is required for a
fully chip-independent interface (and future library), but doesn't break
the interface and cannot be used by the current libsensors, so we can give
ourself some delay.
I will of course make the changes everywhere at once (all drivers and
library, documentation) so that applications using libsensors won't be
affected at all.
For those interested, the original thread on the lm_sensors mailing-list is
available here:
http://archives.andrew.net.au/lm-sensors/msg06206.html
And an older one on the same topic:
http://archives.andrew.net.au/lm-sensors/msg05028.html
Pavel Machek suggested, "Sounds good, what you probably need is to submit patch
doing step #1 to Andrew" [Morton] "and see what happens..." Jean replied,
"Patches are on their way to Andrew as we speak, thanks to Greg :)"
10. Status Of 2.0 Port Of uClinux
18 Feb - 22 Feb (9 posts) Archive Link: "[PATCH]: linux-2.6.3-uc0 (MMU-less
fixups)"
People: David Weinehall, Greg Ungerer
Greg Ungerer announced an update of uClinux (http://www.uclinux.org/pub/uClinux
/uClinux-2.6.x/linux-2.6.3-uc0.patch.gz) , and David Weinehall asked, "Any
plans for a 2.6-version of the ARM-support?" Greg replied, "Yes. There is some
code available now, although it is not complete and doesn't fully work yet. It
really needs more cleaning up before it will be interresting or useful to
anyone." David asked, "How's the status of the 2.0-port of uClinux, btw? Is it
unintrusive enough to be considered for a 2.0-merge?" Greg replied, "Hmm,
probably not. It is no where near as clean as the 2.6 merge. It could be
cleaned up, but no one seems to interrested in doing the work." David said,
"Well, if there are users and interest, I could do at least some of the work.
Since I've already done some work with 2.0 uClinux, and since I'm the 2.0
maintainer, I do have some experience ;-)" And Greg replied, "There are still
users. I was planning on merging in your 2.0.40 code sometime soon, to bring
the uClinux 2.0 sources up to date at the very least. But if you feel like
doing it, that would be good too :-)"
11. Hot-Swapping Linux Kernels
19 Feb - 20 Feb (9 posts) Archive Link: "Hot kernel change"
Topics: Microkernels: Mach, User-Mode Linux
People: Jim Richardson
Carlos Silva asked if it were possible to switch the kernel of a running
system, without a reboot. Jim Richardson suggested, "What you could do, is use
MkLinux, (is that still around?) It had the ability to run simultaneous
kernels, IIRC, then you might be able to gradually push over new processess to
the new kernel, and eventually, kill the old one." Carlos got very excited
about this, and Jim added:
I have no idea if it is still in development. To be clear, it doesn't allow
you to simply replace a kernel, but to add a second one, and possibly, to
start transferring over tasks to it.
You can do much the same thing with user mode linux also. Again, not a
kernel replacement in that sense, but something similar, sort of.
12. udev 018 Released; Starting To Be Fully Usable; Some udev Docs
19 Feb - 23 Feb (26 posts) Archive Link: "[ANNOUNCE] udev 018 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Klibc, Version Control
People: Greg KH, Michael Buesch
Greg KH said:
I've released the 018 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-018.tar.gz (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-018.tar.gz)
rpms built against Red Hat FC2-test1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-018-1.i386.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-018-1.i386.rpm)
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-018-1.src.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-018-1.src.rpm)
udev allows users to have a dynamic /dev and provides the ability to have
persistent device names. It uses sysfs and /sbin/hotplug and runs entirely
in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run.
Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/
pub/linux/utils/kernel/hotplug/udev-FAQ)
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs)
Major changes from the 017 version:
+ We now handle the ability to generate all partitions for a device to
allow removable devices to work in a sane manner. This has been
requested by a lot of people.
+ there's a new %s{} modifier available for people to use
+ the SYSFS_ style rule has changed to SYSFS{}. The old style is still
supported for now, but you have been warned
+ %c1 style modifiers has been changed to %c{1}. Again, the old style
format still works.
+ scsi_id is built by default now in the rpm and is available in the
pre-built rpm package. This should get it a wider range of testing.
+ lots of bug fixes and other cleanups.
In all, there is nothing hugely major in this release, but any current
users of udev will want this version for all of the bugfixes if for nothing
else.
Thanks to everyone who has send me patches for this release, a full list of
everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
He replied to himself, saying:
As of this release, I've been running with udev managing my /dev for me
exclusively on my main email and development machine. This is a major
milestone for udev and it proves that it is a viable solution.
I'd like to say thanks to everyone who has made this possible to do:
+ Pat Mochel for creating sysfs and listening to my crazy ideas about how
we could create a userspace devfs all those years ago.
+ Dan Stekloff for prodding me to actually implement this crazy idea and
who came up with a solid initial design document, without which this
project would have never left the dream stage.
+ Kay Sievers for almost single-handedly taking over the whole udev TODO
list and converting udev from a small "proof of concept" toy into a
powerful and useful tool.
+ Pat Mansfield for creating the scsi_id tool and enabling udev to call
external programs, which instantly made udev a real tool in the fine
Unix tradition.
+ All of the Gentoo developers who integrated udev into their distro and
showed me that it can actually run a machine.
+ everyone who has sent in udev patches, bug reports, and feature
requests. Without these udev would only work for me, and not the rest
of the world. A community is very important.
+ the distros for picking up udev without me having to beg :)
+ everyone else who I know I've forgotten...
udev development isn't done, but for anyone who has not checked it out yet,
I suggest you do so. I'll post a small HOWTO that shows how to configure
udev to manage your /dev without any problems or legacy issues (the 2.4
kernel will still work just fine on the same box.)
If anyone has any suggestions for things that are lacking in udev, please
let me and the linux-hotplug-devel mailing list. This especially goes for
any distro developers who are trying to integrate it into their systems.
Michael Buesch replied:
I'm running udev for some time now on my main development machine and it
works (almost) great. Thanks Greg and all the others who made it possible!
But I've a little issue left. My parallel port doesn't show up in /udev. I
guess it's because of missing sysfs support? I'm running linux-2.6.3.
I did not find an entry for the parallel port in sysfs. If I create the
device node manually I can access lp.
Greg replied, "Yes, that driver has not been converted to use sysfs yet. It's
on the list of drivers to convert, only 162 more to go... :("
Elsewhere, Greg said:
Here's a small document that I've added to the udev tarball that explains
how I managed to get udev to manage my /dev tree on a Red Hat Fedora based
machine. All you Gentoo developers can just laugh as it's already
integrated into your distro.
Any users of other distros, feel free to send me updates to this to show
how to do it for yours. Any distro maintainers, feel free to just integrate
udev into your system so this kind of tweaking isn't necessary :)
He gave the document:
HOWTO use udev to manage /dev
This document describes one way to get udev working on a Fedora-development
machine to manage /dev. This procedure may be used to get udev to manage /
dev on other distros, if you modify some of the steps.
This will only work if you use a 2.6 based kernel, preferably the most
recent one. This does not prevent your machine from using a 2.4 kernel, if
you boot into one, udev will not run and your old /dev will be present with
no changes needed.
NOTE NOTE NOTE NOTE NOTE NOTE NOTE
This is completely unsupported. Attempting to do this may cause your
machine to be unable to boot properly. USE AT YOUR OWN RISK. Always have a
rescue disk or CD handy to allow you to fix up any errors that may occur.
NOTE NOTE NOTE NOTE NOTE NOTE NOTE
+ Build and install udev as specified in the README that comes with udev.
I recommend using the following build options to get the smallest
possible binaries:
make USE_KLIBC=true USE_LOG=false DEBUG=false
+ disable udev from the boot process by running:
chkconfig udev off
or
chkconfig --del udev
as root.
+ place the start_udev script somewhere that is accessible by your
initscripts. I placed it into /etc/rc.d with the following command:
copy extras/start_udev /etc/rc.d/
+ modify the rc.sysinit script to call the start_udev script as one of
the first things that it does, but after /proc and /sys are mounted. I
did this with the latest Fedora startup scripts with the patch at the
end of this file.
+ make sure the /etc/udev/udev.conf file lists the udev_root as /dev. It
should contain the following line in order to work properly.
udev_root="/dev/"
+ reboot into a 2.6 kernel and watch udev create all of the initial
device nodes in /dev
If anyone has any problems with this, please let me, and the
[email protected] mailing list know.
A big thanks go out to the Gentoo developers for showing me that this is
possible to do.
13. Linux 2.6.3-mm2 Released
20 Feb (4 posts) Archive Link: "2.6.3-mm2"
People: Andrew Morton, Ari Pollak
Andrew Morton announced 2.6.3-mm2, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3/
2.6.3-mm2/
+ More parport fixes/cleanups from Al Viro
+ Various patches were folded together to make them a bit more logical.
-mm has less than 200 patches for the first time in a long time. Things
are actually slowing down.
+ Added an absolutely gargantuan MIPS update.
+ More CPU scheduler changes.
+ 2.6.3-mm2 builds and runs on x86 and ia64, and compiles on x86_64 and
ppc64.
Ari Pollak asked, "It seems that include/linux/modsetver.h was removed, which
means that I can no longer build the madwifi driver. Is there something that's
supposed to replace this?" But there was no reply.
14. device-mapper Updates
20 Feb - 23 Feb (17 posts) Archive Link: "device-mapper patchset"
Topics: Ioctls
People: Joe Thornber
Joe Thornber said:
Here's another device mapper update, some of these are quite big patches,
so I'll run through the list:
endio method
We've been using this code for many months (years?). Needed for the more
complicated targets.
Remove the version-1 ioctl interface
This didn't get in last time I submitted it. Leave it out if you still
disagree.
Audit for list_for_each_*entry*
Trivial, please merge
Queue limits
Please merge.
List targets ioctl
Adds a command that lets tools query the kernel to see what targets/
versions are available.
Multipath target
People really want this, so I'm probably pushing it sooner than I'd like.
It would be good if it got a wider audience in the -mm tree or as an
experimental target in vanilla.
15. Linux Stability Page Updated
20 Feb - 23 Feb (3 posts) Archive Link: "[Announce] New Updates to the Linux
Stability Page"
People: Craig Thomas
Craig Thomas said:
The Linux Stability page continues to post test result data for the post
2.6.0 kernels. http://www.osdl.org/projects/26lnxstblztn/results/
Below lists some recent changes to the page (in case you haven't visited in
a while).
1. 2.6.x kernels tested upon release:
-mm
-rc
-bk
2. Detaild Test Result Links show links to continual updated results to
re-aim-7, tiobench, and iozone tests run in STP (1-way, 2-way, 4-way
and 8-way, as appopriate)
3. New links to database performance reports in the Database Performance
Reports section (replaces old database section)
4. New section added to link to various Lilnux kernel test report
If anyone knows of other useful test result information or information
providing a current state of the Linux kernel that can be linked from this
page, let me know and I'll add the link.
16. iswraid Update For 2.4
20 Feb (2 posts) Archive Link: "Announce: updated "iswraid" (ICH5R/ICH6R
ataraid sub-driver) for 2.4.25"
Topics: Disk Arrays: RAID, Disks: IDE, Disks: SCSI, Serial ATA
People: Martins Krikis, Jeff Garzik
Martins Krikis said:
Attached to this email is a gzipped patch for the next revision of the
Intel Software RAID driver "iswraid" (which is an ataraid subdriver) for
the 2.4.x series kernels. The patch is taken against kernel 2.4.25 with
Jeff Garzik's 2.4.25-libata1.patch already applied. (This driver is useless
without libata.) My apologies about the size and the binary nature of this
attachment.
Also attached is a very small patch that enables (partial?) Intel's ICH6R
chipset's SATA support in the ata_piix driver. I am sure that Jeff can
enable this properly (or perhaps already has), but for those who find the
chipset unidentified, this may be a quick fix. ICH6R is then usable in both
the IDE and RAID modes.
The driver is intended to be used with Intel's ICH5R/ICH6R chipsets.
Configuration of RAID volumes is done from the Option ROM. This "iswraid"
driver differs from the other ataraid sub-drivers in that it operates on
SCSI block devices rather than the ATA/IDE ones. The "ata_piix" driver
(part of libata1) presents the SATA disks connected to ICH5R/ICH6R chipsets
as SCSI disks. The "iswraid" driver is considered experimental, use at your
own risk.
Thanks to Boji Kannanthanam for answering my questions and to Jeff Garzik
for providing a great low level driver to utilize.
He added that this wasn't his own contribution, but was provided by Intel.
17. List Of fbdev Issues
22 Feb - 26 Feb (37 posts) Archive Link: "fbdv/fbcon pending problems"
Topics: Framebuffer
People: Benjamin Herrenschmidt
Benjamin Herrenschmidt reported:
Here's a list of pending issues with fbdev (either upstream or in the fbdev
bk treee), I figured posting it here may help getting more people on those
issues as my time is sparse and I suppose James too.
+ First one, I will deal with, just writing it for completeness: When
switching from KD_GRAPHICS to KD_TEXT (either same console changing
mode or switching to a different console), we need a callback so the
fbdev has a chance to restore the accel engine setting (or even the
whole mode, to be safe).
+ Memory corruption problems. There is still at least one identified when
using stty. Just use crazy values, like flipping rows & cols (like stty
rows 132 cols 30) and usually, you'll see the box blow up very soon
with heavy memory corruption.
+ mach64 lockups on LT-G (I'll try on an LT-Pro soon) plus other mach64
bugs in the new version in the bk fbdev, I'll have a patch for some of
the problems, but I didn't find a good explanation for the accel
lockups yet
+ Logo problems. When booting with a logo, then going to getty, the logo
doesn't get erased until we actually switch to another console (or
reset the console). At this point, using things like vi & scrolling up
doesn't work properly. Actually, last time I tried, I had to switch
back & forth twice before my console that had the logo got fully
working with vi.
+ Back buffer problem: maybe related to the logo ? After boot, doing
shift-pageup to go back to the boot message, usually you get crap
displayed at various places.
+ On x86, various junk displayed when the fbdev takes over. Reported by
radeonfb users, I couldn't test myself, I don't have an x86 with radeon
at hand for the moment. Apparently, the takeover from vgacon doesn't
properly "convert" the previous VGA text buffer content
+ stty & mode picking. Currently, fbcon_resize() (called when stty is
used to resize the console) will hack a "var" strcture by just putting
new width/height in it and pass that to set_var. The way the various
drivers react to that mostly broken "var" structure is rather random.
We need to explicitely differenciate between a mode that is "complete"
(like what fbset or X passes down the fbdev) or a mode that is just
width/height and eventually a hint of frequency, like what fbcon passes
in this case. I added FB_ACTIVATE_FIND for that purpose, but that needs
better driver support to "pick" up a proper mode. The algorithm for
that isn't trivial. Could be moved to common code.
+ fbset doesn't resize the console. I consider that a regression from
2.4. I have some code based on the notification mecanism to address
that, but it tends to trigger the same memory corruption problem as
reported with stty & bogus coordinates. There is something hairy going
on with console resizes. That code is a bit foreign to me though.
Ok, that's all that comes to my mind right now, help is welcome :)
18. Bluetooth SysFS Support
23 Feb - 25 Feb (14 posts) Archive Link: "Please back out the bluetooth sysfs
support"
Topics: FS: sysfs
People: Christoph Hellwig, David S. Miller, Marcel Holtmann
Christoph Hellwig said:
The patch '[Bluetooth] Initial sysfs and device class support', is the
usual misguided sysfs conversion attempt levaing oopsable races, so please
back it out until the bluetooth folks have understood and cared for the
lifetime rule issues of using the driver model.
Guys, if you do use the driver model you have to adhere to it's life time
rules. And that's most importantely you _must_ free the device only in it's
->release routine.
And no, the code doesn't warn about the lack of a release method only that
everyone adds an empty one, sigh..
David S. Miller said, "Ok Christoph, I'm taking to Marcel about what we'll do,
and thus it'll be resolved within the next day one way or another. Thanks for
pointing this out."
A few posts down the line, Marcel Holtmann said, "I converted all Bluetooth
drivers to allocate the hci_dev structure and it will be freed with the release
function of the Bluetooth class. The patch looks big, but most of them are
simple changes. Please review it before I am submitting it to Dave." After some
discussion, Christoph and others sounded off in favor of the patch, and the
thread ended.
19. Status Of ATI IXP150 Southbridge Support
23 Feb - 26 Feb (6 posts) Archive Link: "Support for ATI IXP150 Southbridge"
Topics: Disks: IDE, USB
People: Bartlomiej Zolnierkiewicz
Phil Thompson asked if anyone was working on adding Linux kernel support for
the ATI IXP150 Southbridge, particularly the IDE and USB devices. Bartlomiej
Zolnierkiewicz replied, "IDE support should be added soon (thanks to ATI)."
Phil volunteered to help test the code, and Bartlomiej said, "You can find
experimental (I have not tested it!) driver for 2.6.3 kernel at: http://
www.kernel.org/pub/linux/kernel/people/bart/atiixp_ide/atiixp_ide-2.6.3-1.patch
. It was written by Hui Yu <[email protected]>, additional fixes/cleanups by me."
Phil tried it out, and had good success; meanwhile, Bartlomiej posted an
updated patch at http://www.kernel.org/pub/linux/kernel/people/bart/atiixp_ide/
atiixp_ide-2.6.3-2.patch.
20. Libsysfs v1.0.0 Released
24 Feb (1 post) Archive Link: "[ANNOUNCE] Libsysfs v1.0.0 release"
Topics: FS: devfs, FS: sysfs
People: Ananth N Mavinakayanahalli
Ananth N Mavinakayanahalli said:
Release 1.0.0 of Libsysfs is now available as part of the sysfsutils
package at:
http://linux-diag.sourceforge.net
Libsysfs provides APIs to access the sysfs filesystem for device
information.
Major changes in this release include:
+ A comprehensive testsuite to exercise APIs exported by Libsysfs. An
easy to use config file is provided so users can modify appropriately
for the system under test.
+ Improvements to "refresh" functions (udev requirement).
+ dlist elements now stored in sorted order.
+ A reworked systool for better output.
+ A number of miscellaneous bugfixes.
udev has been shipping with more or less the latest code for quite a few
releases now.
Thanks to everyone who have been using the library and providing valuable
feedback.
21. New Teletex Decoder SAA5246A Driver
25 Feb (5 posts) Archive Link: "[ANNOUNCE] new driver for teletext decoder
SAA5246A"
People: Michael Geng, Andrew Morton
Michael Geng said:
I would like to introduce a new device driver for the I2C based Videotext/
Teletext decoder SAA5246A from Philips. The interface is identical to the
existing driver for the SAA5249 chip. User programs can access these
devices via /dev/vtx0 ... /dev/vtx31.
Templete was drivers/media/video/saa5249.c, some of the SAA5246A
functionality was taken from the original driver from Martin Buck (http://
home.pages.de/~videotext/). In order to make the driver sources easier to
understand I added lots of symbolic constants related to the data sheet of
the SAA5246A from Philips.
The driver is available as a patch to the linux kernel version 2.6.3 from
http://www.michaelgeng.de/linux/saa5246a-2.6.3.patch
I know that today's TV cards do no more have such a teletext processor chip
on board, they use the CPU for decoding videotext pages. This is much
faster if you want to extract all the pages from a TV station for reading
like a journal. I also wanted to change to the vbi interface but after some
trial I went back to decoding via SAA5246A because there were more errors
in the pages decoded with the vbi interface than with the vtx interface
using a SAA5246A. I don't know why. And have you tried to capture a special
subpage from a page that contains 10 suppages or more? When it is finally
transmitted after 10 Minutes you will have to wait for another 10 Minutes
if your CPU missed it. According to my experience a teletext processor will
more probably capture the page.
Of courde I have tested the driver both as a module and compiled into the
kernel. It is licensed under the GPL.
After some back-and-forth with Andrew Morton, he made an update, and posted a
new location (http://www.michaelgeng.de/linux/saa5246a-rev1-2.6.3.patch) .
Andrew was pleased, and said he'd accept the patch.
22. Reiser4 Snapshot Against 2.6.3
25 Feb (1 post) Archive Link: "Latest Reiser4 Snapshot"
People: Hans Reiser
Hans Reiser said:
new reiser4 snapshot against 2.6.3 kernel is available at
http://www.namesys.com/snapshots/2004.02.25
It contains bug fixes and stability improvements. On-disk format is
compatible with the previous snapshot. Also,
+ raid0 preliminary support, and
+ improved loop back support
were added.
In "standard" configuration reiser4 is stable except for a multiple umount/
mount issue we are still analyzing. See the READ.ME file for
not-well-supported features and options.
Hopefully our next snapshot will be ready for inclusion, and hopefully it
is just a few days away.
23. Linux 2.4.26-pre1 Released
25 Feb - 26 Feb (7 posts) Archive Link: "Linux 2.4.26-pre1"
Topics: Power Management: ACPI
People: Marcelo Tosatti
Marcelo Tosatti said:
Here goes -pre1.
It contains a big SCTP merge (to match 2.6 API), networking updates,
network driver updates (including the addition of nVidia Force driver).
Also includes ACPI upstream merge, amongst others.
24. BitMover Openlogging Server Moved
25 Feb (1 post) Archive Link: "[BK] openlogging has moved"
People: Larry McVoy
Larry McVoy said:
We've moved the openlogging server back to San Francisco and updated the
DNS entries. BK users should be just fine but if anything appears strange
let us know.
One side effect of this is we're making the web pages work again, should be
going today or tomorrow.
25. Linux 2.6.4-rc1 Released
27 Feb - 1 Mar (6 posts) Archive Link: "Linux 2.6.4-rc1"
Topics: Networking
People: Linus Torvalds
Linus Torvalds said:
Ok, as usual, there was a lot of stuff for the -rc1, but as seems to be
more and more true it is mainly in the "periphery".
This is a big patch, but the bulk of it is a long-overdue MIPS update, and
the (working) HFS/HFS+ filesystem update (total rewrite), and ISDN updates.
And some large s390 driver updates too, for that matter.
So please keep bigger updates to yourself, and let's calm this down.
26. BitMover Updates openlogging.org Server
28 Feb (1 post) Archive Link: "[BK] http://www.openlogging.org"
People: Larry McVoy
Larry McVoy announced:
We've moved the openlogging server back to San Francisco and updated the
DNS entries. BK users should be just fine but if anything appears strange
let us know.
One side effect of this is we're making the web pages work again, should be
going today or tomorrow.
27. Status Of pmdisk; Removal Considered
28 Feb - 2 Mar (41 posts) Archive Link: "Dropping CONFIG_PM_DISK?"
Topics: Software Suspend
People: Pavel Machek, Karol Kozimor, Benjamin Herrenschmidt
Pavel Machek asked, "Would there be any major screaming if I tried to drop
CONFIG_PM_DISK? It seems noone is maintaining it, equivalent functionality is
provided by swsusp, and it is confusing users..." Benjamin Herrenschmidt and
others felt that there was some sense in keeping the code, but when Pavel asked
him if he would be willing to maintain it, Benjamin said no. Pavel replied,
"Well, unless someone steps up, I guess I'll just let it bitrot, and when its
broken enough, I'll attempt removal. I really do not have time to maintain two
implementations..."
Elsewhere, Karol Kozimor said of CONFIG_PM_DISK, "It may be ugly, it may be
unmaintained, but I get the impression that it works for some people for whom
swsusp doesn't. So unless swsusp works for everyone or Nigel's swsusp2 is
merged, I'd suggest leaving that in." Pavel asked for more information about
when pmdisk worked in a situation when swsusp did not. A number of folks
offered their experiences, although it was clear that neither mechanism was
perfect.
28. FUSE Filstystem Interaction With SELinux
29 Feb - 1 Mar (9 posts) Archive Link: "[SELINUX] Handle fuse binary mount
data."
People: James Morris, Christoph Hellwig, Andrew Morton, H. Peter Anvin
James Morris said, "This patch ensures that fuse filesystems are able to be
mounted with SELinux enabled." Christoph Hellwig took a look at the patch and
made an ugly face at a bit of code that addresses specific filesystems
directly. He said, "Umm, binary mount data is bad enough, but hardcoding
filesystem-depend code in selinux is just bogus.." Andrew Morton added, "Yes,
it's rather awkward. Could we do something such as passing a new mount flag in
from userspace? Add a new flag alongside MS_SYNCHRONOUS, MS_REMOUNT and
friends?" H. Peter Anvin said the best thing would be a flag exported by any
registered filesystem. James Morris suggested that the problem seemed "like a
property of the filesystem type: perhaps add FS_BINARY_MOUNTDATA to fs_flags
for such filesystems, per the patch below. We also need to change one of the
LSM hook arguments." H. Peter agreed.
29. Linux 2.6.4-rc1-mm1 Released
29 Feb - 2 Mar (22 posts) Archive Link: "2.6.4-rc1-mm1"
Topics: POSIX
People: Andrew Morton, Christoph Hellwig, Bill Davidsen
Andrew Morton announced 2.6.4-rc1-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4-rc1/
2.6.4-rc1-mm1/
+ Added the POSIX message queue implementation. We're still stitching
together a decent description of all of this. Reference information is
at
http://www.mat.uni.torun.pl/~wrona/posix_ipc/
and
http://www.opengroup.org/onlinepubs/007904975/basedefs/mqueue.h.html
+ A fair amount of work against the page reclaim code. Mainly
reorganisation and simplification of various little glitches. This
means that a few of the optimisations which were in 2.6.3-mm4 were
broken and were dropped. But this is a better basis upon which to
reintroduce them.
Performance, however, seems similar to 2.6.3-mm4 in a few tests.
Inter-zone balancing is much better than 2.6.3 but still could be
improved a little.
Slab reclaim balancing is improved, however with some (artificial)
workloads slab is still being a problem because of tremendous internal
fragmentation problems: 6% occupancy of the pages which are allocated
to dcache, for example. More work is needed to account for this.
I tested the swapout code with 7.2G of tmpfs pagecache on a 7G machine.
The rotate_reclaimable_page() logic seems to work fine here - only 200M
of memory was added to swapcache and was swapped out.
+ Plus the usual various little fixes and cleanups.
+ The contents of the broken-out/ directory are now available in the
2.6.4-rc1-mm1-broken-out.tar.gz file. This includes the `series' file
which describes the patching order.
People who are using patch-scripts can recreate the patching machinery
by doing:
cd /usr/src/linux
tar xfz ~/2.6.4-rc1-mm1-broken-out.tar.gz
mv broken-out/*.patch patches
mv broken-out/series .
for i in $(cat-series series)
do
pcpatch $i
done
rmdir broken-out
In the Changelog, Andrew also listed that he had fixed "scsi.h for inclusion by
userspace apps - it used to work, so..." But Christoph Hellwig replied, "This
has been rejected on linux-scsi a few times. Don't use include/scsi/ from the
kerneltree - there's alredy a /usr/include/scsi from glibc anyway, so the
situation is even more clear than the general you should not include kernel
headers thing." Andrew replied, "hm, OK. If it works in 2.4 and doesn't work in
2.6 I'd consider that a regression. And as the fix is so trivial, I'd consider
failure to fix it as pure dogmatism. But whatever, I'm utterly bored of this
discussion. Consider it dropped." Bill Davidsen objected:
But the glibc headers don't describe 2.6, do they? Don't work with 2.6? We
went around with this for cdrecord unless I misread which headers are
involved.
It's not reasonable to expect people to rebuild glibc for each kernel, even
if it is "the right thing to do" in some purist sense. It would be better
to have something like user header in the kernel for just the interface,
and have the kernel include start by pulling in the user header and then
adding things the user doesn't need.
Changes between kernel series are always unpleasant during the time when
people have to boot back and forth, we should think about a better way to
do this for 2.7.
But there was no reply.
30. Developers Plan kgdb Patch Submission
3 Mar (6 posts) Archive Link: "Code freeze on lite patches and schedule for
submission into mainline kernel"
People: Amit S. Kale, Pavel Machek
Amit S. Kale said:
We have two sets of kgdb patches as of now: [core-lite, i386-lite, 8250]
and [core, i386, ppc, x86_64, eth]. First set of kgdb patches (lite) is
fairly clean. Let's consider it to be a candicate for submission to
mainline kernel.
I am freezing the lite patches wrt. feature updates. Only bug-fixes and
code cleanups will be allowed in lite patches. You can make any feature
enhancements to second set of patches.
I propose following schedule for pushing kgdb lite into mainline kernel:
Take 1: 8th , Take 2: 15th, Take 3: 22nd, Take 4:29th. I'll download the
kernel snapshot (http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/) on
these dates and submit a single patch for possible acceptance into mainline
kenrel and feedback from community. Hopefully we'll succeed by end of this
month.
Please checkin any fixes or cleanups by end of this week. I plan to add
some documentation to core-lite.patch this week (will send it for review in
a separate email)
Pavel Machek approved of this whole plan, but he said, "There may be better way
to get kgdb into mainline. AFAICS, mainline already contains kgdb/ppc.
Submiting "core-lite, ppc-lite, 8250" would then be simply much needed cleanup.
We can push i386 few days after that." But Amit replied:
ppc.patch removes arch/ppc/kernel/ppc-stub.c and adds a new file kgdb.c I
think that has a greater rejection chance.
Let's not change the direction now. Some time ago there was another view
that x86_64 would be easier. We have already had sufficient headache
because of split -lite -heavy patches. Let's try to finish that asap.
Pavel agreed that this made sense, and the thread ended.
We Hope You Enjoy Kernel Traffic
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.