Kernel Traffic #203 by Zack Brown
[email protected] Fri, 31 Jan 2003 09:36:23 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <E18ef5T-0005hz-00@renegade> |
Kernel Traffic #203 For 31 Jan
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 18 Jan - 24 Jan (19 Not All Developers Certain Of Linux Success
posts)
2. 21 Jan - 23 Jan (9 Quota Support For Non-ext2 Filesystems
posts)
3. 22 Jan - 27 Jan (33 Specialized Hardware Emulation For Linux
posts) Sandbox
4. 22 Jan - 26 Jan (15 Aic7xxx 6.2.28 And Aic79xx 1.3.0 Released;
posts) Developer Disconnect
5. 23 Jan - 25 Jan (17 Mailing List Policy; FAQ Maintenance
posts)
6. 24 Jan (4 Getting Started With Linux Hacking
posts)
7. 25 Jan (1 Documentation For SoftIRQs, Tasklets, Timers,
post) And Work Queues
8. 25 Jan - 28 Jan (13 New Modversions Implementation For 2.5
posts)
9. 26 Jan (1 RivaTV 0.8.2 Released
post)
10. 26 Jan - 27 Jan (11 2.5.59-mm6 Released
posts)
11. 28 Jan (1 Syscalltrack 0.81 Released
post)
Mailing List Stats For This Week
We looked at 1677 posts in 6967K.
There were 490 different contributors. 236 posted more than once. 223 posted
last week too.
The top posters of the week were:
* 63 posts in 231K by Andre Hedrick
* 61 posts in 186K by Richard Stallman
* 44 posts in 248K by (Hell.Surfers)
* 43 posts in 189K by Andrew Morton
* 33 posts in 124K by Larry McVoy
* Full Stats
1. Not All Developers Certain Of Linux Success
18 Jan - 24 Jan (19 posts) Subject: "Linux in the News! WooHoo!"
Topics: Disks: SCSI
People: Andre Hedrick, James Simmons, Jesse Pollard
Andre Hedrick reported:
http://eastbay.bizjournals.com/eastbay/stories/2003/01/20/story1.html
The hardcopy edition is better. It has sweet little TUX snacking on a
Windows Logo! Go to http://eastbay.bizjournals.com/eastbay/ next saturday
and see this weeks print cover on the web!
James Simmons replied:
Linux will NEVER move into the desktop market!!! Linux has found it niche
in the server market and some aspects of the embedded market. Well it is
struggling to keep alive in the embedded space. Why is this?
Number one reason it will never move into the desktop market is the free
beer mentality. Alot of people expect something for nothing or next to it.
I not just talking users. Even multi-billion dollar companies. I had a
large company tell me "You are charging us? That is not very open source of
you!!" As for end users the same problem exist. Plus companies toke note
that it would cost them money to hire some to port their software.
The only reason linux toke off the last few years is because companies
thought it could make pure profits by using free stuff. Well they are
discovering linux does have a cost. You have to actually hire programmers
and you need people to actually understand linux. We will see linux
adaption slow down if not come to a halt in all markets except the server
and none GUI interface embedded devices such as telecom devcies.
Some at this point might stand up and shout what about PDAs. First this is
a very vertical market. In the real world you see lots of Palm Pilots and a
few iPAQs here and there. I never seen a linux PDA in large use. iPAQs can
run linux but they will never ship will linux. I worked with several
experimental PDAs. Several that never made it to market and even more the
companies deceided linux was to immature compared to Windows CE so moved to
using a M$ product.
What is the immature? The bare basics is stable and fine but people want
more than just to login in via a serial console. I seen alot of nice
development of new types of GUI. Out of the few dozen vendors all but one
decided not to go with X windows. BTW that one moved over to windows CE
later. These companies felt X was a hinderance. So they went to other GUIs
like microwindows or embedded Qt. Still there is a lack of apps and a even
greater lack of comapnies wanting to write apps for linux PDAs.
Now for the issue of the desktop itself. We have the basic two problems
above. The biggest issue with X is the long developement cycle. The good
news is since NVIDIA, which makes there own X server and drivers, is the
dominate graphics card we don't feel it so much. If we had 20 to 30
graphics cards with equal market space we would notice. Especially when the
graphics cards were have 6 month cycles before they become obsolete.
So what is my PROOF of all this. First take a look at the linux jobs out
there. You will notices System Admin jobs. Several of those in fact. Then
the development jobs are iSCSI or network card or some other aspect of
network programming. Now look for a GNOME or KDE programming job outside of
a distro looking to hire someone. I seen only one in Austalia. Now try a
search in flipdog.com, CareerBuilder.com, or HotJobs.com for a GNOME or KDE
jobs. Well what do you know. No jobs avaible. So no company is looking to
either port there software to linux nor create new linux software. Mind you
a few companies tried like lokigames. Now they are gone. Next level is
graphics and multimedia programming in linux. Again nothing really
avaiable.
Now the next question is what companies invest in non sever related
matterial for linux i.e mulitmedia, GNOME, KDE, X outside of the distros. I
know people there are people on the list from IBM, HP etc who are reading
this email. Speak up if this in not the case. The only one I knew of was VA
linux. They hired several of the DRI/X windows developers. To my knowledge
they no longer work there. So the only companies pursing non server related
are the distros. Now the question is hwo many will be left soon. One of
them filed for a form of bankruptcy a few days ago. Very few remain. Also
we are seeing the strongs one move to where the money is. The server
market. So I wouldn't count on any R&D from anyone to much to move linux to
the desktop.
Jesse Pollard pointed out that, "X is a serious load unless you are expecting
to work with multiple hosts, all sending windows back to the same server. In
which case, nothing else works as well, nor as portably. Any standard X
application can display to any reasonably standard X server." He also pointed
out that long development cycles for the X Windowing System had mainly to do
with poor hardware specifications. James agreed with this, but said, "but also
due to the fact that many of the people involved do this in there spare time
versus for a living. 5 hours a week versus 40 makes a big difference in how
fast something comes to completion." And Jesse replied, "According to the
XFree86 web pages - they have a LOT of corporate sponsors contributing both
money, jobs, and equipment. They do get paid back by being able to generate
custom graphics interfaces for their hardware."
Jesse, in his original response, also said that there were plenty of Linux jobs
available; and various folks compared notes on the job searches they'd
performed. Results differed wildly.
2. Quota Support For Non-ext2 Filesystems
21 Jan - 23 Jan (9 posts) Archive Link: "why isn't quota dependant on ext2?"
Topics: FS: ReiserFS, FS: ext2, FS: ext3
People: Oleg Drokin, Andrew Morton, Pete Zaitcev, Chris Mason, Gerhard Mack
Gerhard Mack thought that 'quota' support only worked on ext2 filesystems, and
asked why the quota configuration option was not dependent on ext2. But Oleg
Drokin replied, "reiserfs works with this quota code too. Chris Mason working
on porting the patch from 2.4 to 2.5." And Andrew Morton also said to Gerhard,
"ext3, ufs and udf also use the core quota code." Gerhard pointed out that the
documentation said that quota only worked with ext2. He asked where to find
tools to use it under ext3. Andrew said ext3 used the same tools as ext2, and
gave a link to the Sourceforge site (http://quota-tools.sourceforge.net/) . But
Pete Zaitcev also said to Gerhard, "The bad news is that quota on ext3 is
virtually guaranteed to deadlock, so you can do it, but you do not want to do
it. The original memo describes a deadlock in RH 2.4.18-5, which I assure you,
was NOT fixed in Marcelo 2.4.20. A good anti-deadlock work was done, granted,
but this particular one wasn't fixed." Jakob Oestergaard said he'd been using
quota under ext3 on a heavily loaded system, and had found no lockups so far.
However, Andrew acknowledged that there was a problem, saying, "Darnit, I had
all that working 18 months ago ;)" He said, "Let me crunch on that a bit..."
Gerhard thanked Andrew and said he'd wait for the patch, and also reminded him
to fix the documentation that said quota only worked with ext2.
3. Specialized Hardware Emulation For Linux Sandbox
22 Jan - 27 Jan (33 posts) Archive Link: "Simple patches for Linux as a guest
OS in a plex86 VM (please consider)"
Topics: Virtual Memory
People: Kevin Lawton, Valdis Kletnieks, Derek Fawcus, David Lang, Pavel Machek
Kevin Lawton reported:
I'm working on running Linux as a guest OS inside a lightweight cut-down
plex86 environment. My goal is to run a stock Linux kernel, which can be
slimmed down to the essentials via kernel configuration, since a guest OS
doesn't need to drive much hardware.
For this, there's a few critical but simple diffs to macro'ize the use of
the PUSHF and POPF instructions, due to broken semantics of running stuff
using PVI (protected mode virtual interrupts). The rest of the stuff I
believe can be monitored effectively by the VM monitor.
Would you please consider integrating these diffs before 2.6? There's only
one new header file, and macro substitution for a few cases where these
instructions are used. For a normal compile, there are zero logic changes.
Just 1:1 macros.
Pavel Machek asked for some more explanation. Wasn't plex86 supposed to be a
complete machine emulation, that could run any x86 operating system? If so, why
were any patches needed? Kevin replied:
I gutted the old plex86 code, eliminated all the fancy stuff and it now
does nothing except provide a VM container to run user-privilege code only.
X86 is reasonably VM'able at user priviliege, but not so at kernel
privilege.
Plex86 is a kernel module which runs on the host OS. It provides a separate
set of page tables, segment registers and other stuff so that there is no
interference with the host structures, nor dependence on them whatsover.
The thrust behind these simple mods is to be able to "push" Linux kernel
code (when running as a guest OS) down to user level. In this case, it can
also be run in what is now an extremely light-weight VM. To do this, proper
maintenance of the interrupt flag (x86) is necessary, since behaviour of
this flag in the eflags register is different at user-level. The x86
architecture provides a mechanism for this, called PVI (protected mode
virtual interrupts), although the logic for this was not carried over to 2
instructions (PUSHF/POPF). Thus my patches...
Other than that, plex86 "shadows" the guest page tables and discovers the
guest page tables on-demand. So nothing special needs to be done. Access to
system registers trap from user code, so the VM monitor can handle those
properly.
About 99% of the work of a full x86 VM is on handling less than 1% of the
cases. So the new plex86 angle is, forget doing all the fancy work for 1%.
If you're running a VM friendly OS (like Linux with my small patches), you
end up with a potentially high performance and Open Source VM, with very
little work.
As well, plex86 can bolt on to bochs for accelerating user code, reverting
back to bochs for emulation of kernel code - perhaps good for running
non-Linux, and for debugging Linux kernels.
But for the normal case of running Linux VMs, plex86 will be a standalone.
Because the non-essential IO stuff can be configured out of Linux, and the
remaining essential IO can be monitored very lightweight style in plex86 -
even right in the VM monitor for high performance.
To the '99% of work for 1% of cases' argument, Valdis Kletnieks replied:
One of the first implementations of VM was by IBM, called CP/67. It
eventually evolved into VM/370 and its follow-ons.
The initial design reason for CP/67 was to allow 2 or more MVS development
teams to share a system for testing, so the other team could keep working
while the first team debugged a system crash with tools better than the
lights-n-switches at the console.
It turns out that the 99% of the work to cover the 1% of the cases is
really important. The usual reason for doing VM is to isolate images from
each other - and if you don't cover that last 1%, a programming error in
one of the images can nuke your supervisor code into oblivion. It may be a
"VM friendly OS like Linux", but it can still oops in strange ways. For
starters, what happens if you run a Linux *without* your patches under
plex86? ;)
Now if you think about it, and not covering the 1% case is deemed
acceptable, that's OK too. But it's something that needs to be considered.
Kevin said:
Plex86 can 100% isolate guests from each other. What I'm saying is, it
takes 99% of the work to do a full x86 VM which doesn't need those 2 macros
for PUSHF/POPF. (my oversimplified, but yet useful explanation of the state
of affairs)
You have to do a lot of work to "get under the hood" of an OS, to fix up a
few cases where if you let them run native, they'll get the wrong
information or make the wrong thing happen. Not to the other guests, but to
themselves. So if you don't need to do those things, you can let them run
without all the black magic.
He also suggested taking the conversation to private email, but Derek Fawcus
thought the topic was interesting and relevant. He said:
One thing that seems to have been alluded to but not explicity stated is
just where is this patch going, and what affect will happen when running a
non 'VM friendly' OS under the 'new plex86'.
One thing that I'm curious about is how say thing'd work when running a
linux host, with a VM-friendly linux client, and say a Win-2k client.
I assume that the Win-2k client woudl end up having to trap to a simulator
(bochs) for it's ring 0 stuff. But would things in the above scenario work
nicely, with proper isolation between the two (or more) clients?
Kevin explained, "The effect of a non VM'able guest would be it would go into
the weeds. And that effect is irrelevant to the LK list, be you interested or
not. Because that involves no particular issues of Linux as a host nor guest,
not the simple patches I submitted." He again urged folks to take the
discussion off-list, but David Lang remarked:
it sounds like you are saying that with the plex86 you have two ways to
load a client OS.
1. 'normal', full isolation of VMs no modification of the client OS
needed.
2. 'nice VM'. modification of the client OS required, but with the
exception of the kernel level commands being eliminated in the
modification full VM isolation is still provided. Much better
performance then case #1
if you load a client OS and tell the system that it's a #2 when it's really
a #1 then you don't have valid isolation, but that's a sysadmin error that
you will allow to happen in order to make #2 possible.
is this correct?
Kevin replied:
No, there's always full isolation. If a guest is run without mods similar
to the ones I submitted for Linux, the interrupt behaviour will not work
correctly for the guest. Neither the host nor other guests will be
affected. Nor do I care, because this is not for running arbitrary guest
OSes.
x86 does not have pure VMability. So, rather than trying real hard to get
under the hood to make it VM'able with heavy software techniques, just
forget about running all guest OSes and run ones that can work, like Linux.
If you look, you'll notice my patches do nothing except macroize the pushf/
popf instructions to un-break the handling of eflags.IF inside PVI mode
(since x86 breaks it). This has nothing to do with isolation of the guest
OS. Nothing to do with running Windows. Nothing to do with anything except
running Linux as a guest.
4. Aic7xxx 6.2.28 And Aic79xx 1.3.0 Released; Developer Disconnect
22 Jan - 26 Jan (15 posts) Archive Link: "Aic7xxx 6.2.28 and Aic79xx 1.3.0
Released"
Topics: BSD: FreeBSD
People: Justin T. Gibbs, David S. Miller, Matthias Andree, Sam Ravnborg
Justin T. Gibbs announced Aic7xxx 6.2.28 and Aic79xx 1.3.0, saying:
GNU patch relative to 2.5.59:
http://people.FreeBSD.org/~gibbs/linux/SRC/
aic79xx-linux-2.5.59-20030122-gnupatch.gz
BK send and tarball distributions:
http://people.FreeBSD.org/~gibbs/linux/SRC/
aic79xx-linux-2.4-20030122.bksend.gz
http://people.FreeBSD.org/~gibbs/linux/SRC/
aic79xx-linux-2.5-20030122.bksend.gz
http://people.FreeBSD.org/~gibbs/linux/SRC/
aic79xx-linux-2.4-20030122-tar.gz
http://people.FreeBSD.org/~gibbs/linux/SRC/
aic79xx-linux-2.5-20030122-tar.gz
Driver update diskettes for most distributions:
http://people.FreeBSD.org/~gibbs/linux/DUD/aic7xxx/
http://people.FreeBSD.org/~gibbs/linux/DUD/aic79xx/
RPMs for most distributions:
http://people.FreeBSD.org/~gibbs/linux/RPM/aic7xxx/
http://people.FreeBSD.org/~gibbs/linux/RPM/aic79xx/
Changes since the driver versions incorperated in 2.5.59:
[email protected], 2003-01-22 15:09:24-07:00, [email protected]
Bump aic79xx driver version number to 1.3.0, now that it has passed
functional test.
[email protected], 2003-01-22 14:44:51-07:00, [email protected]
Update Aic7xxx and Aic79xx driver documentation.
[email protected], 2003-01-20 16:46:37-07:00, [email protected]
Aic7xxx Driver Update 6.2.28
o Add some more DV diagnostic code
o Fix bug that caused sequencer debug code to be
downloaded always.
Aic79xx Driver Update 1.3.0.RC2
o Correct a regression in RC1 that effectively limited DV to just ID 0.
o Add some more DV diagnostic code
o Misc code cleanups.
[email protected], 2003-01-17 14:49:42-07:00, [email protected]
Aic7xxx and Aic79xx Driver Update
Force an SDTR after a rejected WDTR if the syncrate is unkonwn.
[email protected], 2003-01-17 13:20:53-07:00, [email protected]
Bump aic7xxx driver version to 6.2.27.
[email protected], 2003-01-17 13:17:49-07:00, [email protected]
Aic7xxx Driver Update:
o Determine more conclusively that a BIOS has initialized the
adapter before using "left over BIOS settings".
o Adapt to upcoming removal of cmd->target/channel/lun/host in 2.5.X
o Fix a memory leak on driver unload.
o Enable the pci_parity command line option and default to pci parity
error detection *disabled*. There are just too many broken VIA
chipsets out there.
o Move more functionality into aiclib to share with the aic79xx driver.
o Correct a few negotiation regressions.
o Don't bother doing full DV on devices that only support async transfers.
This should fix a few more of the reported problems with DV.
Aic79xx Driver Update
o Add abort and bus device reset handlers.
o Fix a memory leak on driver unload.
o Adapt to upcoming removal of cmd->target/channel/lun/host in 2.5.X.
o Correct a few negotiation regressions.
[email protected], 2003-01-17 12:18:22-07:00, [email protected]
Aic79xx Driver Update
Enable abort and bus device reset handlers for both legacy
and packetized connections.
[email protected], 2003-01-17 12:10:23-07:00, [email protected]
Aic7xxx and Aic79xx DV Fix:
Don't bother with DV if the device can only do async
David S. Miller quipped, "Justin, I haven't checked, but have you deleted my
change again to include asm/io.h in aix7xxx_osm.h? You keep doing this, I wish
you'd stop :-)" He added, "More seriously, you really need to look at the build
etc. fixes people put into your driver in 2.5.x, it is rude to keep deleting
such changes over and over again." Justin said David should look at the patches
before accusing him of leaving stuff out. They quipped back and forth for
awhile, David pointing out that Justin dropped patches and failed to sync up
with official trees; and Justin saying that no one was infallible, and that he
had in fact included the bit of code David was complaining about. The
conversation degenerated gradually, and at one point Justin said, "I get all of
this grief *after* I already included the change instead of after the first
time I missed it. You really make me laugh!" David replied:
I'm glad that we've established that we both provide endless amounts of
comedy for each other.
Look Justin, the fact remains that you get paid top dollar to maintain the
Linux Adaptec driver. If you can't be bothered to reliably integrate fixes
that show up in Linus's and Marcelo's tree, then that's regretfully sad
given your circumstances.
Now that is what makes me laugh!
At this point Matthias Andree broke in with:
David,
this is not how distributed development can work. The communication clearly
is broken here.
Regardless of whether Linus' tree is broken or no, ALWAYS Cc: the fixes --
even if trivial -- to the driver maintainer. It's as simple as that.
Same about complaints. If a tree breaks, complaining to the maintainer in
addition to Linus/Marcelo/Alan may yield a "Linus' merge is incomplete,
here's the missing bit" message from the maintainer.
It's all about communication. If maintainers drown in messages, they'll
tell this (Linus for example is notorious for dropping messages).
I don't mean to offend anyone, but what you expect looks like clairvoyance
to me, regardless of whether Justin gets paid or not, this is simply not
reasonable to expect.
Unless someone comes up with a "watchmydriver" script that checks the
ChangeSet figures of a set of files after every bk pull and complains if
Linus' tree complains unauthorized ChangeSets. I'm not sure if there is an
invariant tag that remains across getting bk patches applied or if real
diffs are needed. Larry or other BK experts might know more.
But Sam Ravnborg objected:
That is not how things works out. Doing trivial changes to 10+ Makefiles
does not require to bother 10+ arch maintaners. Same goes for trivial fixes
for any subsystem.
Linus pointed out what to do:
Keep a copy of the kernel used for last sync.
Take a copy of latest kernel.
Do a diff of all relevant files, and apply that before submitting.
When it was brought up last time, someone came with a small script to do
so. No bk magic or other stuff needed, and I see that used by many arch
maintainers - otherwise they would loose to many trivial changes.
5. Mailing List Policy; FAQ Maintenance
23 Jan - 25 Jan (17 posts) Archive Link: "Server down?"
People: David S. Miller, John Bradford, Eli Carter, Richard Gooch, Pete Zaitcev
Someone complained that they hadn't been seeing any linux-kernel traffic in a
few days, and wondered if perhaps the mail server had gone down. John Bradford
said that the person had probably been unsubscribed for some reason; and
suggested resubscribing. But David S. Miller said:
This is absolutely NOT WHAT YOU SHOULD DO.
You should INSTEAD, send a mail to [email protected] asking why
you were removed.
People who continually keep resubscribing eventually get black listed. This
means DO NOT DO IT. Ask why you are being removed so that the problems at
your site can be fixed.
When an address bounces, it puts a major burdon on both vger and the
postmasters here.
John replied:
No, infact what you are suggesting is absolutely not what you should do -
the postmasters are already overworked, and don't need to be troubled as a
first resort.
Please, read the FAQ. If you wish to embarrase yourself on this mailing
list, that is up to you, but please do not make me look stupid, AND THERE
IS NO NEED TO SHOUT YOUR INCORRECT ADVICE.
The relevant section of the FAQ is:
Section 3, subsection 14
"I am not getting any mail anymore from the list! Is it down or what?"
Note that there is NO problem with any of the original poster's
mailservers, they are all accessible, so it is not a case of mail getting
bounced from some of them.
The FAQ actually says, "Just resubscribe. Majordomo will get you a nice
note saying you're still subscribed if suddenly everybody went dumb".
It also says, "Asking for help from [email protected] could
expedite the issue.", but common sense suggests that it's best to try
re-subscribing at least once before contacting the already overworked
postmasters.
David pointed out that he was one of those overworked postmasters; and Eli
Carter asked David to update the FAQ to properly cover this issue. David agreed
the FAQ needed to be updated, but Pete Zaitcev pointed out that only Richard
Gooch, the FAQ maintainer, could do an update.
6. Getting Started With Linux Hacking
24 Jan (4 posts) Archive Link: "contributing"
People: Paul Larson, Hanna Linder, Randy Dunlap, Randy Dunlap
Jim Ny just finished an operating systems class and was champing at the bit to
start squashing Linux bugs. Paul Larson replied, "Testing is a good way to
force yourself to learn something. http://ltp.sourceforge.net" Hanna Linder
also said to Jim, "Check out http://bugme.osdl.org. It is a 2.5 kernel tracker
database and if you search for all New but not Assigned bugs then you will see
bugs that need to be worked on. Find one that you think you can do and send a
patch out to this list for review. Also a good starting point is http://
www.kernelnewbies.org." And Randy Dunlap put in, "The kernel janitors project
also has entry-level openings. You can check out the todo list there. http://
kernel-janitor.sourceforge.net and http://sourceforge.net/projects/
kernel-janitor"
7. Documentation For SoftIRQs, Tasklets, Timers, And Work Queues
25 Jan (1 post) Archive Link: "willy's unreliable guide to softirqs, tasklets,
timers and work queues"
People: Matthew Wilcox
Matthew Wilcox said:
my paper from linux.conf.au (http://linux.conf.au) is available from
ftp://ftp.uk.linux.org/pub/linux/willy/lca/
in both TeX and pdf formats. I'd like to turn this into documentation
that's more suitable for linux/Documentation, but that's for a later time.
I'll probably not check my email for the next week, so don't expect an
immediate response.
8. New Modversions Implementation For 2.5
25 Jan - 28 Jan (13 posts) Archive Link: "[RFC] [PATCH] new modversions
implementation"
Topics: Kernel Build System
People: Kai Germaschewski, Rusty Russell, Richard Henderson, Keith Owens
Kai Germaschewski announced:
Here's a patch which adds module symbol versioning to 2.5. The old
implementation had been broken with rusty's module rewrite and been
disabled in the kernel config.
The idea behind the patch is the same as in the old implementation, i.e.
add checksums to exported symbols which change as the ABI changes. Modules
also record the version checksums of the ABI they are built against. When
loading a module into the kernel, those two checksums (per symbol) are
checked against each other to make sure that the ABIs are compatible.
The implementation is basically completely different from the old code
(which was well-known for "do make mrproper when something goes wrong"),
the idea used partially dates back to discussions on linux-kbuild/Keith
Owens/Rusty Russell, and the current code is based in part on a patch by
rusty.
A kernel built with CONFIG_MODVERSIONING will continue to work fine with
unpatched module-init-tools, however, forcing the load of a module with
mismatched symbol versions will need a small patch to module-init-tools.
Rusty Russell was thrilled with this work, but complained, "you are relying on
link order to keep the crcs section in the same order as the ksymtab section
(although the ld documentation says that's correct, I know RTH" [Richard
Henderson] "doesn't like it)" . But Richard Henderson said, "What gave you that
idea? Link order is a fine thing to rely on." Rusty accepted this, and the
thread ended.
9. RivaTV 0.8.2 Released
26 Jan (1 post) Archive Link: "Announce: RivaTV 0.8.2 released"
Topics: Version Control
People: Yuri van Oers
Yuri van Oers announced:
Version 0.8.2 of the RivaTV package has finally been released.
!!Users of a recent CVS version of RivaTV are advised to keep using CVS!!
0.8.2 is already greatly outdated by CVS, expect 0.8.3 soon.
http://rivatv.sourceforge.net/
10. 2.5.59-mm6 Released
26 Jan - 27 Jan (11 posts) Archive Link: "2.5.59-mm6"
Topics: Disk Arrays: RAID, FS: ReiserFS, FS: devfs, FS: ext3
People: Andrew Morton
Andrew Morton announced:
http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.59/2.5.59-mm6/
+ Some rework and restructuring of the anticipatory scheduling code.
The reported slowdown in RAID1 rebuild _may_ have been fixed. At least,
it doesn't happen for me with this patchset.
+ The request aliasing problem hasn't been fixed yet, so this kernel (and
2.5.59) will still fail under heavy direct-IO load.
+ The mysterious "machine hangs late in boot" problem has been narrowed
down thanks to some great work by Andres Salomon. The machine is stuck
waiting on I/O completion when performing the initial lookup for /sbin/
devfs_helper:
Thread 11 (Thread 10):
#0 io_schedule () at include/asm/atomic.h:122
#1 0xc014cd0a in __wait_on_buffer (bh=0xd3fe45b0) at fs/buffer.c:132
#2 0xc014dfa6 in __bread_slow (bh=0xd3fe45b0)
at include/linux/buffer_head.h:260
#3 0xc014e1c8 in __bread (bdev=0x0, block=0, size=0) at fs/buffer.c:1385
#4 0xc0181774 in ext3_get_inode_loc (inode=0xd3d697bc, iloc=0xd3d13ce0)
at include/linux/buffer_head.h:235
#5 0xc0181841 in ext3_read_inode (inode=0xd3d697bc) at fs/ext3/inode.c:2205
#6 0xc0183db4 in ext3_lookup (dir=0x0, dentry=0xd3d4cae0)
at include/linux/fs.h:1199
#7 0xc01585fb in real_lookup (parent=0xd3d4cce0, name=0xd3d13d94, flags=0)
at fs/namei.c:372
#8 0xc0158849 in do_lookup (nd=0xd3d4cae0, name=0xd3d13d94, path=0xd3d13d84,
cached_path=0xd3d13d8c, flags=-1071144428) at fs/namei.c:537
#9 0xc01589ef in link_path_walk (name=0x0, nd=0xd3d13dc8) at fs/namei.c:651
#10 0xc01558c1 in open_exec (name=0x0) at fs/exec.c:454
#11 0xc0156200 in do_execve (filename=0xd3d6d000 "/sbin/devfs_helper",
argv=0xc133bd08, envp=0xd3d13dc8, regs=0x0) at fs/exec.c:1032
#12 0xc0107e0d in sys_execve (regs=
{ebx = -1071125472, ecx = -1053573880, edx = -1071125308, esi =
-740448672, edi = 0, ebp = -741261356, eax = 11, xds = -1072562053,
Which _looks_ like a request queueing problem, but Andres says it goes
away when devfs is disabled in config. So I've dropped the smalldevfs
patch for now - would be appreciated if devfs users could retest this
patch, with CONFIG_DEVFS=y.
+ There appears to be a CPU utilisation problem with
reiserfs_file_write.patch - but it doesn't oops or corrupt data so I've
left that in for now while Oleg scratches his head over that one.
11. Syscalltrack 0.81 Released
28 Jan (1 post) Subject: "ANN: syscalltrack 0.81 "Cruel Ducky" released"
People: Muli Ben-Yehuda
Muli Ben-Yehuda announced:
syscalltrack-0.81, the 13th alpha release of the Linux kernel system call
tracker, is now available. syscalltrack supports version 2.4.x of the Linux
kernel on the i386 platform.
This release containes several important bug fixes and new features.
* What is syscalltrack?
syscalltrack is made of a pair of Linux kernel modules and supporting user
space environment which allow interception, logging and possibly taking
action upon system calls that match user defined criteria. syscalltrack can
operate either in "tweezers mode", where only very specific operations are
tracked, such as "only track and log attempts to delete /etc/passwd", or in
strace(1) compatible mode, where all of the supported system calls are
traced. syscalltrack can do things that are impossible to do with the
ptrace mechanism, because its core operates in kernel space.
* Where can I get it?
Information on syscalltrack is available on the project's homepage: http://
syscalltrack.sourceforge.net, and in the project's file release.
The source for the latest version can be downloaded directly from: http://
osdn.dl.sourceforge.net/sourceforge/syscalltrack/syscalltrack-0.81.tar.gz
or any of the other sourceforge mirrors.
* Call for developers:
The syscalltrack project is looking for developers, both for kernel space
and user space. If you want to join in on the fun, get in touch with us on
the syscalltrack-hackers mailing list (http://lists.sourceforge.net/lists/
listinfo/syscalltrack-hackers).
* License and NO Warranty
syscalltrack is Free Software, licensed under the GNU General Public
License (GPL) version 2. The 'sct_ctrl_lib' library is licensed under the
GNU Lesser General Public License (LGPL).
syscalltrack is in _alpha_ stages and comes with NO warranty. We put it
through extensive testing and routinely run it on our systems, but if it
breaks something, you get to keep all of the pieces.
* PGP Signature
All syscalltrack releases from now on will be signed. This release is
signed with my pgp public key, which you can get from http://www.mulix.org/
pubkey.asc or via 'gpg --keyserver wwwkeys.pgp.net --recv-keys 0xBFD537CB'
We Hope You Enjoy Kernel Traffic
Kernel Traffic is hosted by the generous folks at Tux.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.