|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
linux-kernel FAQ | subscribe to linux-kernel | linux-kernel Archives | kernelnotes.org | LxR Kernel Source Browser | All Kernels | Kernel Ports | Kernel Docs | Gary's Encyclopedia: Linux Kernel | #kernelnewbies
Table Of Contents
| 1. | 5 Dec 2000 - 18 Dec 2000 | (15 posts) | IRQ Routing Problems In Developer Series |
| 2. | 7 Dec 2000 - 8 Dec 2000 | (23 posts) | 2.2 Vs. 2.4 |
| 3. | 7 Dec 2000 - 17 Dec 2000 | (78 posts) | Argument Over Quality Of Red Hat 7.0 |
| 4. | 11 Dec 2000 - 22 Dec 2000 | (18 posts) | kapmd Hogging The CPU: The Saga Continues |
| 5. | 16 Dec 2000 - 18 Dec 2000 | (8 posts) | Difficulties Getting Docs From ServerWorks |
| 6. | 16 Dec 2000 - 17 Dec 2000 | (13 posts) | Link-Order Dependency Problems |
| 7. | 17 Dec 2000 - 18 Dec 2000 | (5 posts) | Benefits Of NFSv3 |
| 8. | 18 Dec 2000 | (4 posts) | Debugging Systems That Use Binary Modules |
| 9. | 18 Dec 2000 | (4 posts) | VM Performance Issues Regarding Memory Allocation |
| 10. | 18 Dec 2000 | (8 posts) | Alan's 2.4 Tree |
| 11. | 18 Dec 2000 | (3 posts) | ATA Specification Available With Click-Through Licence |
| 12. | 20 Dec 2000 - 21 Dec 2000 | (5 posts) | Achieving Greater Compression In Kernel Binaries |
| 13. | 20 Dec 2000 - 22 Dec 2000 | (3 posts) | Hardware-Based Copy-Protection |
Mailing List Stats For This Week
We looked at 1074 posts in 4476K.
There were 369 different contributors. 162 posted more than once. 0 posted last week too.
The top posters of the week were:
1. IRQ Routing Problems In Developer Series
5 Dec 2000 - 18 Dec 2000 (15 posts) Archive Link: "PCI irq routing.."
Topics: PCI, Power Management: ACPI, USB
People: Linus Torvalds, Kai Germaschewski
Linus Torvalds reported:
Ok, I now have two confirmations from independent people (Adam Richter and Kai Germaschewski) who have completely different hardware, but have the same problem: irq routing seems to not work for them.
In both cases it is because the PCI device config space already has an entry for the interrupt, but the interrupt is apparently not actually routed on the irq router.
WHY this happens is unclear, but it could be several reasons:
The problem can be fairly easily fixed by just removing the test for whether "pci->dev" has already got set. This, btw, is important for another reason too - there is nothing that says that a sleep event wouldn't turn off the irq routing, so we _have_ to have some way of forcing the interrupt routing to take effect even if we already think we have the correct irq.
However, Martin is certainly also right in claiming that there might be bugs the "other" way, and just completely dismissing the irq we already are claimed to have would be bad.
This is my current suggested patch for the problem.
Adam, Kai, can you verify that it fixes the issues on your systems?
Anybody else who has had problems with PCI interrupt routing (tends to be "new" devices like CardBus, ACPI, USB etc), can you verify that this either fixes things or at least doesn't break a setup that had started working earlier..
Martin, what do you think? We definitely need something like this, but maybe we could add a few more sanity-tests?
Kai Germaschewski reported success with the patch, but Martin Diehl reported no change in behavior. After some technical back-and-forth with Martin, Linus remarked, "Ok, definitely needs some more work. Thanks for testing - I have no hardware where this is needed." After some more discussion, Linus proposed a simple no-finesse solution after getting access to an affected machine. He asked for more comments, but the thread ended with no definite solution.
2. 2.2 Vs. 2.4
7 Dec 2000 - 8 Dec 2000 (23 posts) Archive Link: "Linux 2.2.18pre25"
Topics: Virtual Memory
People: Alan Cox, Linus Torvalds
This thread featured a cute exchange between Linus Torvalds and Alan Cox. At one point Alan mentioned, "I've been trying to avoid VM fixes for 2.2.18 to stop stuff getting muddled together and hard to debug. Running with page aging convinces me that 2.2.19 we need to sort some of the vm issues out badly," -- and he added with a smirk -- "and make it faster than 2.4test." And Linus replied:
Ahh.. The challenge is out!
You and me. Mano a mano.
3. Argument Over Quality Of Red Hat 7.0
7 Dec 2000 - 17 Dec 2000 (78 posts) Archive Link: "Signal 11"
Topics: Bug Tracking, Compiler, Version Control
People: Linus Torvalds, Jakub Jelinek, Alan Cox, Bernhard Rosenkraenzer, Miquel van Smoorenburg, Michael Peddemors, Theodore Y. Ts'o, Zack Brown, Alex Kanavin, Matt Wilson, John Summerfield, Chris Abbey, Stanislav Meduna, Mike A. Harris, Peter Samuelson, Horst von Brand
This was the now-famous thread in which Linus Torvalds said:
Quite frankly, anybody who uses RedHat 7.0 and their broken compiler for _anything_ is going to have trouble.
I don't know why RH decided to do their idiotic gcc-2.96 release (it certainly wasn't approved by any technical gcc people - the gcc people were upset about it too), and I find it even more surprising that they apparently KNEW that the compiler they were using was completely broken. They included another (non-broken) compiler, and called it "kgcc".
"kgcc" stands for "kernel gcc", apparently because (a) they realised that a miscompiled kernel is even worse than miscompiling some random user applications and (b) gcc-2.96 is so broken that it requires special libraries for C++ vtable chunks handling that is different, so the _working_ gcc can only be used with programs that do not need such library support. Namely the kernel.
In case it wasn't obvious yet, I consider RedHat-7.0 to be basically unusable as a development platform, and I hope RH downgrades their compiler to something that works better RSN. It apparently has problems compiling stuff like the CVS snapshots of X etc too (and obviously, anything you compile under gcc-2.96 is not likely to work anywhere else except with the broken libraries).
Jakub Jelinek replied that the bugs reported against Red Hat's gcc had already been fixed, to which Linus replied, "That's good. It's even better if you don't play quite as fast-and-lose with your shipping compiler." Jakub also responded to Linus' point about Red Hat's gcc requiring special libraries; he said, "Every major g++ release had incompatible libstdc++, even g++ 2.95.2 if bootstrapped under glibc 2.1.x is binary incompatible with g++ 2.95.2 bootstrapped under glibc 2.2.x (libstdc++ uses different soname then; even if we used g++ 2.95.2 we would not have C++ binary compatible with other distributions)." Linus replied:
Yes.
And I realize that somebody inside RedHat really wanted to use a snapshot in order to get some C++ code to compile right.
But it at the same time threw C stability out the window, by using a not-very-widely-tested snapshot for a major new release.
Are you seriously saying that you think it was a good trade-off? Or are you just ashamed of admitting that RH did something stupid?
Elsewhere, Alan Cox also replied to Linus' initial post. Responding to Linus' statement that Red Hat's gcc had not been approved by the gcc technical people, Alan asserted that all but two of Red Hat's patches had been accepted into the upstream sources, which he felt showed their approval of Red Hat's choice. He added, "The naming did upset people and was unfortunate, but done talking to the compiler folks at Red Hat with the best of intentions behind it. If we had called it 'Red Hat cc' I think people would have been even more offended at the way they had been discredited." To Linus' point that Red Hat's gcc was so broken it required special libraries, Alan said, "Wrong - the C++ vtable format change is part of the intended progression of the compiler and needed to meet standards compliance. gcc 295 also changed the internal formats. Unfortunately the gcc295 and 296 formats are both probably not the final format. The compiler folks are not willing to guarantee anything untill gcc 3.0, which may actually be out by the time 2.4 is stable." Linus replied:
If you ask any gcc folks, the main reason they think this was a really stupid thing to do was exactly that the 2.96 thing is incompatible BOTH with the 2.95.x release _and_ the upcoming 3.0 release.
Nobody asked the people who knew this, apparently.
Alan pointed out that gcc 2.95 had a different format, gcc 2.96 had a different format, and egcs 1.1.2 had a different format. So, he said, they all had different formats from all others, except that gcc 2.96 was also a c++ compiler. Bernhard Rosenkraenzer also replied to Linus, saying on similar lines as Alan, "The same thing is true of *any* gcc release. For example, C++-ABI wise, 2.95.x is incompatible BOTH with egcs 1.1.x _and_ the upcoming 3.0 release." But Miquel van Smoorenburg put in:
Yes, but 2.96 is also binary incompatible with all non-redhat distro's. And since redhat is _the_ distro that commercial entities use to release software for, this was very arguably a bad move.
There's simply no excuse. It's too obvious.
Alan accused:
Except you conveniently ignore a few facts
Miquel replied that he'd been half-joking and should have included a smiley. But Michael Peddemors asked, regarding Alan's second item, "Curious HOW do you tell vendors??" To which Alan replied, "When they ask." He went on, "More usefully Dan Quinlann and most vendors put together a recommended set of things to build with and use. It warns about library pitfalls, kernel changes and what packaging is supported. It is far from perfect and nothing like the LSB goals but its a start and following it does give you applications that with a bit of care run on everything." At this point Theodore Y. Ts'o came in with:
In the interests of making sure everyone understands the history:
The Linux Development Platform Specification (LDPS) was started as a result of an informal evening post-LSB-meeting gathering in June --- to which by the way Red Hat didn't send any representatives --- the discussion at the restaurant started along the lines of "Oh, my *GOD* RedHat is about to do something stupid --- they're releasing Red Hat 7.0 with beta/snapshots of just about every single critical system component except the kernel --- and vendors who fall into the trap developing against Red Hat 7.0 won't work with any other distribution. This is going to be *bad* for Linux."
So yes, the reason why LDPS was formed was to recommend to vendors what they should build and use --- but while Alan gave comments about the LDPS once it was announced that a group of people were working on the LDPS , there is no way that the LDPS could even vaguely be considered a Red Hat initiative. (The LDPS is a separate work group which is part of the FSG, so it is a sister group to the LSB effort.)
He added, "Ever since Jim Kingdon left Red Hat (he was at VA Linux for a while, and is now at SGI), as far as I know no one at Red Hat is actively participating in the LSB activities --- they haven't sent anyone to the physical LSB meetings, or participated in the bi-weekly phone conferences, or taken work items to help finish the LSB. Alan does participate on the mailing lists, and makes quite helpful comments, but as far as I know that's about the limit to Red Hat's participation to either the LSB or the LDPS specification work. Speaking as someone who has been contributing time and effort to the LSB, it would be great if Red Hat were to become more fully involved in the LSB; I (and I'm sure all the other LSB volunteers) would welcome a greater level of participation by Red Hat."
There was no reply.
Another threadlet branched out of Alan's initial reply to Linus' first post. To Linus' hope that Red Hat downgrade their gcc as soon as possible, Alan said:
Like what - gcc 2.5.8 ? The problem is not in general that the snapshot is any buggier than before, but that the bugs are in different places. egcs and gcc295 both caused X compile problems too.
I still advise people: Use egcs-1.1.2 for Linux 2.2.x. You can build 2.2.18 with gcc 2.9.6 but I personally wouldn't be running production systems on a kernel built that way - but NOT because gcc296 is buggier but because the bugs are going to be in different places and I firmly believe production system people should let the loons find them ;)
Linus replied:
gcc-2.95.2 is at least a real release, from a branch that is actively maintained - so a 2.95.3 is likely to happen reasonably soon, fixing as many problems as possible _without_ being incompatible like the snapshots are.
Or just stay at 2.91.66 (egcs).
[...]
I'd applaud RedHat for making snapshots available, but they should be marked as SNAPSHOTS, and not as the main compiler with no way to fix the damn problems it causes.
As it is, anybody doing development is probably better off at RH-6.2. That is doubly true if they intend to release binaries.
Alan pointed out that 2.96 was actively maintained -- by CygnusHat -- and that they fed all changes back to the core gcc team. As for marking snapshots as snapshots, Alan said, "That it was confusing and mistaken by some as an official GNU group release is something we never intended and have already apologised for. It was done without malice or ill intent." And to Linus' recommendation that developers use Red Hat 6.2 in preference to 7.0, Alan agreed, saying, "We strongly recommend that people use 6.2 for developing binaries for general release unless they have specific requirements for glibc 2.2. Thats the same guidelines the LSB 'oops we havent finished yet here is a quickie for now' documentation recommends."
Bernhard also replied to Linus' suggestion of 2.95.2 as being actively maintained. Bernhard asserted that it wasn't as actively maintained as it could be, and added that a comparison of numbers of patches in the 2.95 tree against the 2.96 tree in Red Hat's Rawhide distribution would show more activity on 2.96. He added that he didn't think the current 2.96 code was any more buggy than the current 2.95 code. He also went on to say that Linus' suggestion of egcs "may be good for the kernel, but it's not acceptable for C++." Regarding Bernhard's comparison of 2.95 upstream to 2.96 in Rawhide, Linus replied:
Take a look at the differences in linux-2.2.x and linux-2.3.x.
linux-2.3.x is was a h*ll of a lot more "actively maintained".
But nobody really considers that to be an argument for RedHat (or anybody else) to installa 2.3.x kernel by default. Sure, most distributions have a "hacker kernel", but it's NOT installed by default, and it is clearly marked as experimental.
Your arguments make no sense.
The compiler is often _more_ important to system stability than the kernel. A "real release" implies that it at least had testing, and that people know what the problem spots tend to be.
Note that the "know what the problem spots tend to be" is important.
For anyone interested, there was some mention of 2.96 instability in Issue #80, Section #9 (31 Jul 2000: Some Discussion Of gcc/Kernel interactions) . 2.96 was still not recommended by Issue #86, Section #4 (6 Sep 2000: Best Compiler Versions For 2.2 and 2.4) (though Alan felt the problem was more with the kernel than the compiler). Horst von Brand agreed with this assessment in Issue #88, Section #4 (26 Sep 2000: 'gcc' 2.96 And The Kernel) , though Red Hat was already taking flak for releasing their gcc snapshot under the false name 2.96; and Peter Samuelson felt that 2.96 would break any known kernel, in Issue #93, Section #2 (24 Oct 2000: Which Compiler To Use?) .
(ed. [Zack Brown]Personally, I think Red Hat is not vocal enough about encouraging people to participate in development of their distribution. They've hired some truly amazing people to work on it, but the Red Hat distro still seems to suffer from a more closed nature than something like Debian, or the kernel itself.
The only public developer mailing list suitable for actual Red Hat development, for example, tends to stay fairly low traffic and off-topic. I count 133 posts for almost the entire month of December, or 4 to 5 posts a day on average. During the same period, debian-devel got over 2600 posts, or over 80 per day; while linux-kernel got over 4300, or over 140 per day -- more per day than the Red Hat list traffic during the entire month. And of the Red Hat list traffic, the vast majority were user questions. Only three posters had redhat.com email addresses, and their contribution totalled 16 posts. No effort was made to let other folks know that their posts were off-topic, or to explain what the true subject of the list actually was. The only reason I found out is because I asked on the list back in October.
I said, "I've been looking for a Red Hat development mailing list, like debian-devel, where the distro is actually created and improved. It looks like redhat-devel-list is for people doing development of other projects, on a running red-hat system. Am I SOL?" Alex Kanavin replied, "Well, I think nobody is quite sure what this list is for, but you can certainly discuss this sort of thing here. And don't forget that most of the actual development takes place at RH's bugzilla and there's some of it at http://www.labs.redhat.com." He also gave a pointer to the Red Hat Developer Network, but Matt Wilson (of Red Hat) replied, "If you want a developer at Red Hat to read something, the web forums aren't the place to go at the moment. It's right here." Matt also replied to my original post, saying, "you're in the right place. There's just a bit of OT discussion..."
There were several replies to this. John Summerfield said, "last time I looked at the list description (admittedly quite a while ago) the definition of "development" was loose enough to include development of programs. Indeed, this is the reason I originally subscribed." And Chris Abbey added, "actually this is the first time I've seen someone @redhat.com answer this question. I know when I first saw this list I asked the same question and never got an answer... I've seen it a few more times in the last three years. I'm glad to see that statement from Matt. I know it means some of my questions will be moving off this list, but it also gives me more confidence that certain others (like the nfs install tree building script I'm working on) will be directed somewhere that folks @redhat.com will see."
Stanislav Meduna also replied to Matt, saying, "Well, as far as I remember, I have yet to see any real discussion regarding creating and improving the distribution on this list."
Mike A. Harris also replied to Matt, saying, "More like a _LOT_ of OT discussion. ;o) Looks like a lot of people sign up here thinking it is the Red Hat "ask all questions for every release" list (redhat-list). The ontopic to offtopic posts are 1:10 respectively. ;o(" Chris was hopeful that this would change, now that folks knew better what the list was supposed to be about. There was some discussion of ways to keep the list on-topic, and the thread petered out.
Apparently, not much has changed since October. I believe there are several factors contributing to this. First, it's fairly difficult even to find this list (took me awhile), and then to know what to make of it once it's been found. As I saw, many of the list subscribers didn't know they were on the one-and-only public Red Hat distro developer list.
Second, even the Red Hat developers don't post much in the way of ideas about the direction of the project, possible features or new packages, new patches, etc.; they do respond to bug reports when any turn up, but as far as any other real development of the Red Hat distro, the list is empty.
And third -- or perhaps just a summation of the entire problem as I see it -- there seems to be no real leadership, of the sort the bazaar requires in order to thrive. No one is encouraged to work on developing Red Hat. No one has a sense of what sort of work might be accepted into the distro, and what sort of work would be unwanted. There is simply a nebulous entity called "Rawhide", and another nebulous entity called "The Developers". Who are these developers? The mailing list subscriber list is private. The developers themselves, with a few exceptions, are never heard from. The mailing list drags on with no direction. And one day, Red Hat 8.0 comes out.
Some folks might see a hesitation in Red Hat corp. here, and accuse them of trying to suffocate the developer list, so that all development discussion could take place entirely in-house, away from the prying eyes of their competitors. That fear may be the cause of some of the bitterness against Red Hat found from time to time on linux-kernel and elsewhere. I don't know what the truth is, but their current developer list is far from being a pillar of strength to the free software community.
)4. kapmd Hogging The CPU: The Saga Continues
11 Dec 2000 - 22 Dec 2000 (18 posts) Archive Link: "kapm-idled : is this a bug?"
People: Rik van Riel, Nick Holloway, Kurt Garloff
Someone noticed that the kapm-idled process nromally took up between 60% and 80% of the CPU, but only when no other processes were running. Rik van Riel replied, "What do you suppose the 'idled' in 'kapm-idled' stands for?" Nick Holloway replied, "We know it was an attempt to stop people complaining about the fact that "kapm" was hogging the CPU. Looks like it doesn't work." The original poster also replied to Rik, saying that the behavior was misleading, and seemed to show a constantly loaded CPU. And Kurt Garloff put in, "Even worse: Formerly you could take conclusions from the sys part of your load. This is not possible any more. I dislike this as well and consider it a cosmetical bug. (Which is much better than a real bug, don't get me wrong. If fixing the cosmetical one introduces a real one: Don't do it!)" There was some discussion of possible improvements to the situation, but nothing conclusive emerged from the list. For an earlier discussion on this issue, see Issue #89, Section #8 (3 Oct 2000: 'kampd' Hogging The CPU?) .
5. Difficulties Getting Docs From ServerWorks
16 Dec 2000 - 18 Dec 2000 (8 posts) Archive Link: "ServerWorks docs?"
Topics: FS, Networking
People: Rico Tudor, Dave Jones, Dan Hollis, Jeff Nguyen, Matthew Jacob, Jim Forster, J.A. Magallon
Rico Tudor asked, "Does anyone have reference material for the ServerWorks northbridge? I want to add their chipsets to my ECC-monitoring utility, but their web site is little more than marketing drivel. Plus, they don't respond to e-mail." J.A. Magallon gave a link to some ServerWorks drivers. But Dave Jones felt that this page only indicated that "chances of them publically releasing register level info seems pretty slim." He added that he'd tried several times to get docs out of them and failed. Dan Hollis remarked, "serverworks requires you not only to sign an NDA, but also do all development on-site at their santa clara HQ under their direct supervision." But Jeff Nguyen said, "Serverworks wants to support the Linux community. Thus they are willing to share certain information to developers without risking the IP. Recently ASL has been working with Serverworks in supporting the lm-sensor project and other Linux software developer. Let me know if you need some help with the chipset information." Rico replied that without the docs, the basic problem remained. He went on:
My interest in ServerWorks documentation is two-fold: first, to expand chipset support in my ECC utility and second, to better support ServerWorks-based machines in my workplace.
On behalf of the Linux community, I would sign NDA if it was civilized and if my source remained, obviously, public-domain. I could visit ServerWorks on my next foray to the Bay Area.
More important to me is ready access to technical documentation to support machines at work. I come from the era when PDP-11's were shipped with schematics, the OS, and the source to the OS. Things have been going downhill ever since. I'm not catching the next plane to the Bay Area for "eyes only" examination of a document every time a problem arises. In this regard, companies like IBM Storage and Intel win my kudos, and my dollars. ServerWorks may get some of those dollars because they have an affordable chipset that supports 4 GB, but that advantage can change overnight. It's not like IP has a long half-life these days, unless you can corner the pyramid-building business.
These companies must evaluate their proprietary stance in relation to lost sales, the more so as free source accelerates. ATI, Matrox, Adaptec: need we say more? But then, I'm preaching to the choir. Perhaps ServerWorks should look into their hearts, and decide what small part of their IP has enormous, eternal value -- the kind that will have them rolling in dough, just like Scrooge McDuck. The rest of the specification, like the miserable ECC circuitry that's been done a million times before, release it already! Their adoring Linux fans are waiting.
Matthew Jacob had a few factual points to make against Rico's post. First, he pointed out, "The only source for the OS that came 'for free' that I can recall for the PDP-11 was RSX-11- but that was only the bare kernel. The filesystem and the utilities's source wwas not available. At that time, as you can probably well recall, the UNIX source licence from WECO was 40K$ for v7 at Sidereal." Regarding kudos for IBM and Intel, he went on, "Don't applaud either Intel or IBM too loudly. In particular, Intel. Just *try* and get documentation about their frickin' gigabit ethernet chip out of them."
Jeff also replied to Rico, quoting an email from Jim Forster of Serverworks, in which Jim said, "We want to enable the Linux community as quickly as possible; we agree with you that it makes business sense to do so. Given the fact that our IP is our sole product, we cannot release our technical documents to the world at large. We have been working to create an extract of our documents to enable the Linux community. As a small company experiencing tremendous growth, our support infrastructure must focus on our existing customers. At this time, I do not have an estimated release date for the technical extract. ... We are continuing our work to enable the Linux community. Can you think of any alternative methods to enable the Linux community without exposing ourselves? I'm certainly open to new ideas..."
Jeff explained:
Jim responded to my Email regarding support for lm-sensor. Granted Serverworks has not released any information to the public. But they are planing to extract certain chipset information that might be helpful for you. They are also open to idea from the Linux community.
After Jim replied, Phil Edelbock from lm-sensor group came up with a good idea. They decided to ask Jim for a specific set of information pertaining to the project. So rather goes for the whole documentation, they only asked for a small subset. The idea worked because Serverworks were able to supply the information quickly.
This could be a good approach in getting information from Serverwork outside of NDA.
There was no reply.
6. Link-Order Dependency Problems
16 Dec 2000 - 17 Dec 2000 (13 posts) Archive Link: "[PATCH] link time error in drivers/mtd (240t13p2)"
People: Keith Owens, David Woodhouse, Alan Cox
Rasmus Andersen posted a short patch to remove the 'static' declaration of the cfi_probe struct, which caused it not to be shared. Taking this out allowed the kernel to successfully pass the linking process, though Rasmus admitted he wasn't sure if the behavior he'd changed had actually been intended or not. Keith Owens replied that between test11 and test12, someone had added code to do conditional compilation; which, Keith said, added needless complexity and was therefore wrong. He asserted that this earlier change should be undone and the cfi_probe returned to a static declaration. However, David Woodhouse defended the change, pointing out that the conditional complexity was necessary to accomodate variations in linking order. To this, Keith replied, "Messing about with conditional compilation because the link order is incorrect is the wrong fix. The mtd/Makefile must link the objects in the correct order." He listed what he felt to be the proper link order of various .o files, and suggested a link-order change for mtd.h; but David still disagreed with that solution. He said:
The conditional compilation is far more obvious to people than subtle issues with link order. So I prefer to avoid the latter at all costs.
I have to have some conditional compilation in my tree to allow it to compile under 2.0 uClinux. Admittedly that doesn't have to get into 2.4, but I obviously prefer the code in 2.4 to be as close to my working copy as possible.
I'll poke at it and try to come up with a cleaner solution. It may be that I can shift all the conditional stuff off into the compatmac.h and leave the 'real' code path in a cleaner state than the current one.
Keith asked, "The rest of the kernel already depends totally on these "subtle" issues with link order. Why should mtd be different?" Alan Cox chimed, "Why should mtd be broken just because the rest of the Makefiles are?" David also replied to Keith's question, saying, "Because I maintain the MTD code and I want it to be. I think the link order dependencies are ugly, unnecessary and far more likely to be problematic then the alternatives. I'll code an alternative which is cleaner than the current code, and Linus can either accept it or not, as he sees fit." Keith pointed out, "Your choice. Just bear in mind that if CONFIG_MODULES=y but mtd objects are built into the kernel then mtd _must_ have a correct link order. Consider a config with CONFIG_MODULES=y but every mtd option is set to 'y', link order is critical. The moment you have two or more mtd modules built in then you are stuck with link order issues, no matter what you do. Of course you could invent and maintain your own unique method for controlling mtd initialisation order ..." David admitted he had no answer to this problem, and mentioned, "The patch was actually put in by someone to fix 2.0 compilation - and I noticed that it made the link order problem go away for certain configs." He went on, "I'll try to find a clean way to make the MTD code work in all configurations without having to do that. If it really comes to doing the above, I'll probably just give up and let it stay 'broken' (IMO) along with the rest of the kernel code which as you say already has link order dependencies." End Of Thread (tm).
7. Benefits Of NFSv3
17 Dec 2000 - 18 Dec 2000 (5 posts) Archive Link: "mount and 2.2.18"
People: Alan Cox, Andrea Arcangeli
In the course of discussion, Brady Montz asked if anyone knew some docs explaining the benefits of NFSv3. Alan Cox replied, "Not off hand but I can give you a very brief summary of the big one - write speed. NFSv2 does synchronous writes with a minimal amount of write ahead. NFSv3 gathers writes on the server and schedules them as the server wishes. The client sends write requests but before it can assume them completed and thus clear that part of its cache has to commit them. Normally the commit is done well after the I/O hit server disks, if not it waits" and Andrea Arcangeli added, "another relevant feature is that with 2.4.x and 2.2.18aa2 you also get >2G files with NFSv3 (like on top of ext2)."
8. Debugging Systems That Use Binary Modules
18 Dec 2000 (4 posts) Archive Link: "booting without VGA"
Topics: Binary-Only Modules, Disks: IDE
People: Abraham vd Merwe, Alan Cox
Abraham vd Merwe had Linux running on his camera, using the binary-only M-Systems DiskOnChip driver for storage and as a boot device. But he reported, "The problem is if we boot with a kernel WITH vga support enabled, it boots fine. If we disable vga support it doesn't seem to boot. What makes it even stranger is that if we boot with that same non-vga kernel using an IDE disk as boot device it also boots fine." Alan Cox replied, "Please ask M-Systems to debug your problem. We don't have source code to their driver so we cannot help you."
9. VM Performance Issues Regarding Memory Allocation
18 Dec 2000 (4 posts) Archive Link: "VM performance problem"
Topics: Virtual Memory
People: Richard B. Johnson, David S. Miller
Richard B. Johnson noticed what looked like a performance problem in the Virtual Memory subsystem of kernels 2.2.17, 2.4.0-test9, and 2.4.0-test12. He'd written a test program to allocate (via malloc()), use, and then free some RAM. He noticed that all memory would be freed quickly and efficiently if he CTRL-C'ed out of the program, while if the program were allowed to reach its own deallocation code, "it will take even up to 1 whole minute!! At this time, there is an enormous amount of swap-file activity going on." He argued, "Since many programs allocate/deallocate data by setting the break address via malloc(), this represents a severe performance penalty. Deallocating pages should not result in any swap-file activity! This activity should occur only when whatever got swapped out, needs to get swapped back in and nothing needs to get swapped back in during a deallocation! Since user's pages are not reordered (or should not be), there should be no swap activity during page deallocation." David S. Miller asked, "How exactly are these buffers allocated/deallocated? Are you absolutely certain that the deallocation process does not make loads from or stores into the buffers as a free(3) implementation would? That would cause the pages to be sucked back from swap space." Richard replied that he just used free(), as any typical user program might. But David replied, "malloc and free maintain their free buffers pools using linked lists, thus a free() does two stores to the (2 * sizeof(void *)) bytes before or after that buffer. Thus the swapping. Use mmap()/munmap() directly and manage things totally yourself to get rid of this."
10. Alan's 2.4 Tree
18 Dec 2000 (8 posts) Archive Link: "Linux 2.4.0test13pre3ac1"
Topics: FS: VFAT, FS: ext2, FS: ramfs, Networking, PCI, Power Management: ACPI, Sound: i810
People: Alan Cox, Matthew Wilcox, Peter Samuelson, Alexander Viro, Tim Waugh, Linus Torvalds, Tobias Ringstrom, Tjeerd Mulder, Andreas Dilger, David Woodhouse, Geert Uytterhoeven, Jes Sorensen, Jeff Garzik
Alan Cox recently started maintaining his own set of patches against the 2.4-test tree, feeding some to Linus Torvalds for official developer releases. He announced 2.4.0test13pre3-ac1 and said, "This is mostly so people can see what I have merged in my tree and what has gone from it. The patch for the adventurous is in ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4.0test/" and posted the Changelog:
Alexander Viro pointed out that for item 2 (Fix leak in link() syscall), the fix had originally come not from him but from Christopher Yeoh. There was very little other discussion, but Tim Waugh posted some patches.
11. ATA Specification Available With Click-Through Licence
18 Dec 2000 (3 posts) Archive Link: "SerialATA Release, sortof........"
Topics: Disks: IDE, Serial ATA
People: Andre Hedrick, David Weinehall
Andre Hedrick announced:
The Serial ATA specification (500 pages) is now available to the public under certain "click-to-accept" conditions. Click the "specification" link at the bottom of the home page at http://www.serialata.org/. I hope the conditions are acceptable. The file is zipped MS Word.
This just for those that care...please do not ask me for my copy as I am a member of this working group and bound under the NDA.
David Weinehall replied, "Well, I think that most people can be happy with the conditions. Now, the format, that's a completely different issue. With all your influence, I bet you could persuade them to at least run the document through Acrobat Distiller to turn it into a .pdf?!" Andre replied, "My bad for forwarding info from internal. I knew that my copies were in PDF, but did not know if they combined all the erratas in to a newer doc or what...."
12. Achieving Greater Compression In Kernel Binaries
20 Dec 2000 - 21 Dec 2000 (5 posts) Archive Link: "tighter compression for x86 kernels"
Topics: Compression
People: John Reiser, Adrian Bunk, Frank v Waveren
John Reiser announced, "Beta release v1.11 of the UPX executable compressor http://upx.tsx.org offers new, tighter re-compression of compressed Linux kernels for x86. Additional space savings of about 15% have been seen using "upx --best vmlinuz" (example: 617431 ==> 525099, saving 92332 bytes). Both source (GPLv2) and pre-compiled binary for x86 are available." Adrian Bunk pointed out that the project was not fully GPLed, but had a special exception for a portion of the binaries. He gave a link to the text of the license, but Frank v Waveren and John argued that this was merely a case of dual licensing, not of additional restrictions; and John explained, "The UPX team owns all copyright in all of UPX and in each part of UPX. Therefore, the UPX team may choose which license(s), and has chosen two. One of them is GPLv2. The UPX team understands, and fully intends to abide by, its obligations under GPLv2 when any software that is subject to GPLv2 is contributed to UPX and re-distributed by the UPX team. The other license is detailed in the LICENSE file, but may be summarized as: free to use if unmodified, and if used only to invoke the program, and sublicensable only under the same terms. This permits using UPX to pack a non-GPL executable. Users of UPX (as distributed by the UPX team) may choose whether to use UPX according to GPLv2, or according to the other license."
13. Hardware-Based Copy-Protection
20 Dec 2000 - 22 Dec 2000 (3 posts) Archive Link: "CPRM copy protection for ATA drives"
People: Alan Cox, Andre Hedrick
Someone gave a pointer to an article in theregister, discussing hardware-based copy protection. He said the technology seemed easy to defeat, but Alan Cox replied, "Its probably very hard to defeat. It also in its current form means you can throw disk defragmenting tools out. Dead, gone. Welcome to the United Police State Of America." He also added, "I'm just waiting for a few class action law suits against drive manufacturers when people's backup tools cannot cope." To this last, Andre Hedrick replied:
this is one of the issues that I brought up along with many others during the December Plenary Meeting. For the record, I was able to intensify the issue by my objections to postpone the adoption for 60 days. This subject will come up again in February. Since I can only represent my interest as a counsultant to the T13 Committee, because there is not organization offically known as "Linux".
I do expect to take a lot of heat on CPRM, but everyone here knows that I can take as much as I dish it! If you wish to send a note to complain about the issue, I will carry your points to the meeting.
End of thread.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |