| 1. | 19 Apr - 28 Apr | (348 posts) | Development Philosophy Of Unstable Tree; Linus Comments On The FSF |
| 2. | 22 Apr - 24 Apr | (21 posts) | Status Of XFS Merge Into 2.5 |
| 3. | 24 Apr | (3 posts) | Status Of NTFS Support In 2.4 And 2.5 |
| 4. | 24 Apr - 25 Apr | (5 posts) | Bad Kernel Interaction With GCC |
| 5. | 25 Apr - 30 Apr | (2 posts) | Status Of Support For Windows Dynamic Disks |
| 6. | 25 Apr | (2 posts) | Status Of AMD AM29F040B Flash Chip Support |
| 7. | 25 Apr - 28 Apr | (4 posts) | Status Of Patch To Allow Mounting Many Volumes |
| 8. | 27 Apr | (9 posts) | The Nature Of Development Kernels |
| 9. | 28 Apr - 29 Apr | (5 posts) | Some Discussion Of Patch Submission Policy |
| 10. | 29 Apr | (2 posts) | Speeding Up i2c Drivers |
| 11. | 30 Apr | (5 posts) | Which Compiler To Use For Kernel Compilation |
Mailing List Stats For This Week
We looked at 1331 posts in 6447K.
There were 396 different contributors. 196 (49%) posted more than once. 128 (32%) posted last week too.
The top posters of the week were:
In the course of debating the presence of BitKeeper in the kernel documentation, some interesting things were said about something else. Alexander Viro said, "I doubt that dropping -pre completely in favour of dayly snapshots is a good idea - "2.5.N-preM oopses when ..." is preferable to "snapshot YY/MM/DD oopses when..." simply because it's easier to match bug reports that way. Having all deltas downloadable as diff+comment is wonderful, but it doesn't replace well-defined (and less frequent) resync points." Rob Landley said, "The well-defined resync points are the 2.5.N releases. If -pre goes away, then the dot-releases might need to come a little closer together, that's all." And Linus Torvalds replied:
I agree.
I've told myself that I shouldn't have done "-preX" releases at all in 2.5.x - the "real" numbers have become diluted by them, and I suspect the -pre's are really just because I got used to making them during the over-long 2.4.x time.
For development stuff, I think I personally would rather have dailies together with a higher frequency of "real" releases. But as it is now (because it isn't automated), the dailies would be a lot of work..
Pavel Machek replied:
I believe -pre's are still important. Daily snapshots are too likely to be broken, and "real" releases are different from -pre ones (with *usefull* difference): you can ignore -pre release, but you can't ignore real release (because real releases are relative to each other).
Having slightly more frequent real releases would be nice, but I believe it is not feasible to make them as common as pre- patches.
Linus said he'd try to increase the frequency of real releases. He added:
Considering how even real releases in the development tree are likely to be broken (never mind the _trivial_ brokenness of applying the same patch to init/main.c twice, I'm talking about the more fundamental brokenness of just broken drivers and filesystems due to development), I'm not sure how big a deal that is.
And I do make full tar-files of real releases, so that people can skip a few (although unless you have a fast connection it usually only makes sense after 10 full releases or so).
Elsewhere a different subject came up. While discussing the Linux Kernel FAQ, Richard Gooch (FAQ maintainer) promised to add a link to a Free Software Foundation page describing free software. But Linus said:
Please don't.
I don't want a kernel howto quoting the FSF.
Richard replied, "It already has, for years. Like it or not, certain questions/issues *do* get raised. If the FAQ can capture at least some of these, it saves bandwidth on the list." Someone else speculated that Linus "didn't want to endorse the FSF stance that software must be ethically correct." To which Linus replied, "Right. Besides, as the whole notion of "free software" has very little to do with the kernel, please just link to some open source site. One of the more neutral ones is "http://www.debian.org/social_contract.html", for example."
Dan Yocum requested of Linus Torvalds:
I know it's been discussed to death, but I am making a formal request to you to include XFS in the main kernel. We (The Sloan Digital Sky Survey) and many, many other groups here at Fermilab would be very happy to have this in the main tree.
Currently the SDSS has ~20TB of XFS filesystems, most of which is in our 14 fileservers and database machines. The D-Zero experiment has ~140 desktops running XFS and several XFS fileservers. We've been using it since it was released, and have found it to be very reliable.
Daniel Phillips remarked, "The issue is how XFS's private versions of what would normally be generic vfs facilities fit with the rest of the kernel." And Wichert Akkerman also asked, "Has XFS been proven to be completely stable and POSIX complient in its behaviour? The reason I am asking is that XFS seems to be a fairly common factor for segfault bugreports in dpkg. The problems are rare enough (and never reproducable) so I can't prove this but it does leave me wondering." Various folks discussed the reliability of XFS, with the general consensus being that it was about as good as any other filesystem out there. At one point Luigi Genoni said:
the inclusion on XFS in the 2.5 tree would probably move more peole to use it, and so also to eventually trigger bugs, to report them, sometimes to fix them. This way XFS would improve faster, and of course that would be a good thing.
That said, it is important to consider the technical reasons to include XFS in 2.5 or not; if this inclusion could cause some troubles, if XFS fits the requirements Linus asks for the inclusion and what impact the inclusion would have on the kernel (Think to JFS as a good example of an easy inclusion, with low impact).
Various folks discussed the prospect of putting XFS into 2.5, with most folks agreeing that it would be fine, though it shouldn't go into 2.4, because that would be too large a change for a stable series. At one point Daniel said, "It's simply a matter of nobody having done the required analysis to find a really good way to reconcile XFS's way of doing things with mainline vfs. This is time-consuming work that requires a good deal of skill, and right now there are many projects in the same category."
No real decision came out of the discussion.
Anton Altaparmakov announced:
NTFS 2.0.2 for kernel 2.5.9 is now available. This is a small update mainly to incorporate kernel 2.5.9. Also the default fmask is changed to 0177 which means files do not get the executable bit by default. The majority of users prefer it this way. Minor misc bug fixes. Updating is recommended and is necessary if you want to use kernel 2.5.9. Note the patch will work with 2.5.7, too but it may not apply cleanly so you may have to do some minimal & obvious patch work yourself.
You can download patches for kernel 2.5.9 from Sourceforge:
http://linux-ntfs.sf.net/downloads.html
And of course you can use BitKeeper to get our BitKeeper repository at: http://linux-ntfs.bkbits.net/ntfs-tng-2.5
And a on-line view of the repository is available here: http://linux-ntfs.bkbits.net:8080/ntfs-tng-2.5
Erik Andersen asked if Anton planned to port the patches to 2.4, and Anton replied:
Not immediate plans. Eventually yes but right now there are too many other things to do.
But just today someone contacted me and he may be interested in doing the backport...
Anton Blanchard posted a patch to change a variable from static
inline to extern inline, saying, "I noticed on a ppc64 kernel compiled with gcc 3.1 that
context_switch was left out of line. It ended up outside of the
scheduling_functions_start_here/end_here placeholders which breaks wchan.
This is one place where we require the code to be inline, so we should use
extern." Linus Torvalds replied forcefully:
ABSOLUTELY NOT!
"extern inline" does not guarantee inlining. It only guarantees that _if_ the code isn't inlined, it also won't be compiled as a static function.
Complain to the gcc guys, they've made up some not-backwards-compatible thing called "always_inline" or something, apparently without any way to know whether it is supported or not.
Albert D. Cahalan replied:
This is why anything but INLINE or _INLINE (chosen in a Makefile or header) is broken. Every compiler wants something different these days. So, as needed, we get one of:
#define INLINE inline /* sanity! */
#define INLINE extern inline /* an oxymoron */
#define INLINE static inline /* another oxymoron */
#define INLINE __forceinline
#define INLINE __attribute__((always_inline))
#define INLINE inline_me_harder
#define INLINE inline_this_or_I_shove_it_up_your_gnuBTW, I said this during the "extern inline" to "static inline" conversion.
IMHO "extern inline" and "static inline" are oxymorons and, were it not for the silly C99 standard, ought to produce error messsages. They make as much sense as "extern static" does. The compiler's inability to inline something ought to be an error as well. Oh well.
Richard Russon announced:
I've just released v0.0.6 of Linux-LDM which supports Windows Dynamic Disks. Windows 2000 and XP have new partition scheme to support their dynamic volumes.
The source can be downloaded from the project page:
http://linux-ntfs.sourceforge.net/downloads.html
This version should be pretty solid, but if you experience any problems, please let me know. If there are no reports, I'll consider replacing the old driver (2.4.10+) with this one.
Someone asked privately if it it would be possible to use this patch to convert dynamic disks to basic disks, and Richard replied to the list, "The LDM patch just allows the kernel to understand Windows new partitioning. Without it you'll just see one BIG partition of type 0x42. If you only have simple disks on a dynamic disk, then it shouldn't be too hard to convert a dynamic disk back to a basic disk. We don't have a tool to do this yet."
John Tyner posted a patch to support the AMD AM29F040B flash chip in 2.4 kernels, but David Woodhouse replied, "That chip is already supported in the CVS code. The current plan is to wait for 2.4.19 to be released, send the current code to Marcelo for 2.4.20-pre1, and then look at what broke in 2.5, fix it and send the results to Linus."
Pete Zaitcev announced:
I updated my patch that allows to mount unholy numbers of volumes. The old version was for 2.4.9 and did not apply anymore. I split the unnamed majors patch and the NFS patch. Also, CONFIG_ option is gone, because it made the code ugly.
Majors part: http://people.redhat.com/zaitcev/linux/linux-2.4.19-pre7-unmaj.diff
NFS part: http://people.redhat.com/zaitcev/linux/linux-2.4.19-pre7-nores.diff
Userland for NFS: http://people.redhat.com/zaitcev/linux/util-linux-2.11q-nores1.diff
Is anyone actually interested? Random people periodically ask me for patches, get them and disappear into the void. I hear nothing good or bad (well, nothing since Trond reviewed it several months ago, and also someone found a conflict with NFS server code, since fixed). I am thinking about submitting, but if users do not ask, why add extra bloat and negotiate with LANANA...
Panu Matilainen remarked, "I've got quite a few users here who "need" this functionality and it's included in our RH-based custom kernels. Having it as a separate patch for 2.4 is no problem, for 2.5 I'm hoping we finally move to 32bit device numbers..." Pete replied, "Mind, we only ship the unnamed majors part, but not the NFS part. There is no word from util-linux maintainer about required changes to mount(8), so I was cautious about doint that." and Panu said, "Sure, I know. In these cases getting the limit from 255 to around 800 is enough so the mount patch isn't even needed."
Christoph Lameter complained that 2.5.10-dj1 wouldn't even compile. Dave Jones gave a link to his explanation (http://lwn.net/daily/2.5.10-dj1-scsi.php3) of why various features had been disabled (SCSI error handling, in this case), but Christoph replied, "That stuff might be useful in a CVS or BK() source code archive. What is the purpose of releasing a kernel tarball that does not compile? Kernel tarball are there to be compiled and tried out ...." Jerry McBride agreed with this wholeheartedly, but Anton Altaparmakov explained:
First, this is a development kernel, i.e. using it means it may not compile, it may not work, or worse, it may destroy all your data.
Second, the kernel compiles fine as long as you don't make use of any of the currently broken features. A blank statement "the kernel doesn't compile" is more often then not incorrect and should say "the kernel doesn't compile with my .config" instead.
The developmental kernel series is for that... Just as the block layer was "flaky" while Jens was working on it in early 2.5.x and just as IDE is "flaky" at the moment, now scsi is joining the club. (-;
If you want kernels that will compile and work you should be using 2.4.x or 2.2.x kernels...
Dave also explained:
we've gone ~7 full point releases with no updates to the error handling of some drivers. Whilst it seems some maintainers are waiting until the block layer and scsi midlayer frobbing settle down, running these drivers without /any/ error handling is a disaster waiting to happen.
Experiments with new filesystem features is going to be tricky to debug if the scsi drivers are untrustable.
If the maintainers want to continue to wait for 2.5 to settle down, this at least points those interested in getting their hands dirty and fix the problem themselves to the parts that need work.
I debated adding this as a CONFIG_DEBUG_BROKEN_SCSI_DRIVERS or similar when Christoph first sent me the patch. Given how many reports of "xxx being broken" I've had, I'm tempted to do that for -dj2.
Pavel Machek sent a mime-encoded patch to the list, and Stelian Pop pointed to 'Documentation/SubmittingPatches' in the source tree, which indicated that all patches should be sent as plain text. But Alan Cox replied, "Thats just Linus preference. A lot of us prefer to get stuff in attachments because that way there is a reasonable chance their mailer won't have eaten it." David S. Miller added that he also preferred plain text patches.
Murtada Shah asked, "I want to speed up the linux kernel i2c drivers. They are running @ 10Khz now, although i2c is capable of 100. Would anyone be able to point me to the right direction?" And Yves Rutschle replied:
Look in drivers/i2c/*
The details depend on what algorithm your interface uses. For "bitbanging" algorithm for example, timing information is coded in the last parameters of the struct i2c_algo_bit_data.
That said, i2c normally automatically slows down at the speed of the slowest device on the bus, so it may well be that the 10Khz you see has nothing to do with your kernel driver.
Frank Schaefer asked which compiler he should use to build kernels for testing. Gabor Kerenyi replied, "I use 2.95.2 for the test machine and gcc-3.1 from cvs on the other. There's no problem. gcc-3.1 gives a bit more warning. (I use 3.1 at home also) but don't try to use gcc 3.2 because the kernel won't compile in some cases." Roy Sigurd Karlsbakk asked, "Is this common knowledge? Is 3.1 as stable as 2.95.[23]?for compiling the kernel? Does it make any difference in performace?" and Christian Borntræger said:
Not quite.
Gcc 2.95.3 is the recommended compiler for kernel 2.4.10 and later.
We Hope You Enjoy Kernel Traffic
|
All Kernel Traffic and Cousin issues and summaries are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0. |