Kernel Traffic #162 For 14 Apr 2002

By Zack Brown

Table Of Contents

Introduction

I'd like to apologize for the URL I posted in the intro last week. As someone pointed out, the article was complete hear-say, and had nothing to do with official US policy. Next time I'll be more careful.

Mailing List Stats For This Week

We looked at 1356 posts in 6732K.

There were 438 different contributors. 195 posted more than once. 129 posted last week too.

The top posters of the week were:

1. NTFS 2.0.1 For Kernel 2.5.7

28 Mar 2002 - 4 Apr 2002 (16 posts) Archive Link: "ANN: NTFS 2.0.1 for kernel 2.5.7 released"

Topics: FS: FAT, FS: NTFS, FS: UMSDOS, FS: VFAT, Microsoft, Samba

People: Anton AltaparmakovMike FedykRichard B. JohnsonNerijus Baliunas

Anton Altaparmakov announced NTFS version 2.0.1 for kernel 2.5.7, a minor update "to allow binaries to be executed by changing the default permissions on files to include the executable bit. This feature has often been requested by wine users so here it is." Padraig Brady felt this was not the best way to solve the problem. Wine users could run files by giving an explicit path, like 'wine /ntfs/lookout.exe', he said; and setting the executable bit on all files broke things like midnight commander, ls colorizing, shell tab completion, and other things. He gave a link to a discussion (http://marc.theaimsgroup.com/?t=100143416100009&r=1&w=2) of a similar issue with vfat, and suggested making the default read/executre for directories and read-only for files.

Anton read the thread but was unconvinced. He said he'd change it if more folks complained, but he added that he did run executables from the NTFS partition and found the current default useful. He had no problem with shell tab completions, he didn't mind ls showing all green files, and he said Padraig's wine invocation wouldn't work.

Mike Fedyk pointed out, "The difference with NTFS is that there is a possibility to have unix permissions working with it natively, with no extra visible files like with umsdos," but there was no reply. Padraig suggested close by, that the solution was to just mark all files with .exe, .com, or .bat extensions as executable, and bingo! no more problem. But Richard B. Johnson said:

It used to be, under DOS, that ".COM" files were loaded and "executed" even if they were text. Then, when the ".EXE" file came out, it would be executed if the first two bytes were 'MZ' so you could make a text file with the first two characters "MZ" and save it as "CRASH.EXE" and that's what it would do. All ".BAT" files were assumed to be interpreted by 'COMMAND.COM', the "shell", as scripts. This means that you can make a ".BAT" file called "COMMAND.BAT", with interesting results.

When FAT-32, NTFS, VFAT, Windozes file-system(s) were developed all bets are off. Long file-names are the result of a 'container-file' concept and anything goes.

So the only way to guess at these file's execution capabilities is to read the name --and it's a bad guess.

If the files are NOT set to 'executable' as read by Linux, then samba will not work. For the files to be visible to WIN/Clients, they must have all bits set. This 'feature' can be used to make DOS/Win files temporarily off-limits to WIN/Clients (like during a backup).

Mike thought Richard was wrong about that Samba behavior, but Richard insisted, "Try it before you complain. I have samba servers all over the place. If you have a DOS or VFAT file-system mounted and it is accessed by samba as a "share", only the files that are executable will be seen by the clients. Check it out." There was no reply.

Elsewhere, in Anton's initial reply to Padraig's criticism, Anton had said that mc was broken if it couldn't handle file with the execute bit set. He'd said that mc should fire up a binary editor by default. But Nerijus Baliunas replied, "You probably misunderstood the problem - I cannot enter archive files (.tgz, .zip) in mc if these files are marked as executable - mc just tries to execute them."

At one point Padraig pointed out that there had been several folks who did not want the execute bit set by default, and none who'd come forward in favor of it, and asked Anton if that counted as enough complaints to make the change. Anton replied, "I am tending towards a default fmask of 0177 now. I will change it for the next release."

2. Kernel Licensing Discussion

3 Apr 2002 - 8 Apr 2002 (89 posts) Archive Link: "Re: [PATCH 2.5.5] do export vmalloc_to_page to modules..."

Topics: Backward Compatibility, Big Memory Support, Binary-Only Modules, FS: ReiserFS, FS: ext3, Licencing, Version Control, Virtual Memory

People: Alan CoxAndrea ArcangeliTigran AivazianAlexander ViroKai HenningsenLinus TorvaldsIngo MolnarGerd KnorrKeith OwensArjan van de Ven

Scheduler

Andrea Arcangeli changed the vmalloc code to export its API to any code (using EXPORT_SYMBOL), rather than just GPLed code (EXPORT_SYMBOL_GPL). Alan Cox replied:

The authors of that code made it GPL. You have no right to change that. Its exactly the same as someone taking all your code and making it binary only.

You are

but worse than that you are ignoring the basic moral rights of the authors of that code.

A lot of people jumped on Alan for this. First Andrea said that the code in question had not carried any special restrictions or requirements. He said, "from your comment it seems with your _GPL tag you meant to give special licence to the function, that is not obvious at all, I don't find it written anywhere, not even in your above email, so I recommend you to licence your code properly ASAP if you don't want to use the standard licence of the kernel code (like bsdcomp and other piece of sourcecode deos)." Alan replied:

Every single line of code I ever submitted to Linus is -pure- GPL. It bears a GPL header. That includes my part of the vmalloc_to_page work. It has never been available to non GPL modules. You took code I and many others own and exposed it as a library for non GPL users. If they use it that way they are violating copyright law, and they *will* get cease and desist letters.

Anyone using any code of mine in the kernel with non GPL code does so on the basis of the legal doctrine of what is or is not a derivative work, and they do so on their own legal assessment. Taking code I am one of the authors of and making it convenient for people like veritas to use in non GPL code is quite different. Its theft plain and simple.

Tigran Aivazian said, "yes, it should be authors decision (completely agree with you there!) whether a symbol is exported or not and whether it should be exported to all modules or only to some "internal/kernel" modules. But this is a technical issue, nothing to do with legalities/licenses or author's likes or dislikes of binary modules." Elsewhere, he added, "you are saying that Andrea changed some code from being GPL to non-GPL. That is so obviously not true that I am even surprized that I need to point this out explicitly (especially to you; as Jesus said to Nicodemus, are you a teacher in Israel and knowest not these things?)"

Alexander Viro also replied to Alan, saying, "Alan, that's crap. The function in question can be trivially turned into extern inline and removed from export list completely. _If_ such change can be made illegal by exporting uninligned version with EXPORT_SYMBOL_GPL - I'm going to fork the tree *now* and start replacing the stuff exported that way with untainted clean reimplementations. As much as I despise binary-only modules, any mechanism that allows games of that kind needs to be killed. One shouldn't be able to prohibit equivalent transformations of core code (and inlining a function _is_ such transformation) by pulling the licensing crap."

There was no reply to this, but Kai Henningsen also replied to Alan's original comment, saying, "I believe that it is both illegal (by the GPL) and morally bankrupt to add these "GPL only" symbols to the kernel *unless* you can get agreement for them fro *all* kernel copyright holders." To which Alan said, "Other way around. Remember the kernel is GPL not LGPL."

At one point in the discussion, Linus Torvalds came in with:

Well, you're all wrong, bthththt...

Removing the .._GPL() is in this case correct, but not for any of the reasons mentioned, but simply because even Ingo agreed that it shouldn't be _GPL since it's explicitly meant for drivers that shouldn't have any knowledge whatsoever about the VM internals. GPL or not.

The fact that the code was back-ported from 2.5.x and that the _GPL still is there too is just a mistake, partly because I've not gotten any updates from Ingo..

Ingo Molnar replied, "indeed. I had and still have no strong feelings either way, a patch to remedy this was promised by me but not sent. I made it _GPL for pure technical reasons: i saw no non-GPL drivers in 2.5 that used it, and at first sight the functionality looked internal enough to warrant the _GPL export. But in any case, while i might have written some of the patches, the principal author of the final interface is Linus. Hopefully this is the end of this story." Alan also said to Linus:

So Linus is allowed to arbitarily export other peoples contributions ? I think we need to clear this one up and understand what people think the actual rules are around here. As I understand it the original code was

  1. extracted from bttv and is code which I and DaveM partly wrote
  2. was submitted by Gerd who did the extra work and kept it as _GPL when he first exported it. (in 2.4 its relevant to expose it as we have the V4L1 not V4L2 interface)

Nobody seems to have remembered to ask permission around here

But Gerd Knorr said:

No.

I've only submitted the 2.4.x backport to Marcelo, and the only reason I've export it as _GPL there is that it is _GPL in 2.5.x. Having that symbol without _GPL in 2.4 and with _GPL in 2.5 would be very bad style and would upset people who start using that function in 2.4 and notice later on that it is exported more strict in 2.5 ...

I'll happily submit a patch to Marcelo to remove the _GPL once it is gone in Linus 2.5 tree.

The 2.5.x code (which I grabbed for the backport) was submitted by Ingo and updated by Linus says my BK tree changelog. Ingo obviously did *not* a simple cut&paste of DaveM's code from bttv. The 2.5.x vmalloc_to_page() function handles pte-highmem and preemtable kernels, that code was never in bttv.

Elsewhere, Tigran suggested renaming EXPORT_SYMBOL_GPL to EXPORT_SYMBOL_INTERNAL or something, "Then, in the future, one wouldn't have to decide on a case by case basis like we had now (and appeal to Caesar :) because the intention would be clear from the name?" Linus replied, "I agree, that is really the meaning of the _GPL thing, and it would probably also make people react less rabidly to the whole thing." Tigran asked if Marcelo also agreed with this, but Alan said, "Thats a Keith Owens question - will it break current modutils ? I think modutils compatibility for 2.4 must be sacrosanct." Keith replied:

Trivial change to modutils, keeping backwards compatibility, so EXPORT_SYMBOL_GPL == EXPORT_SYMBOL_INTERNAL.

When the flamers and lawyers agree on what they really mean by EXPORT_SYMBOL_GPL or its replacement and everybody agrees on what the keyword should be, let me know and I will roll a new modutils. Otherwise, leave me out of this flamewar.

Tigran embarked:

Let's look at the possible design for 2.5 first, then 2.4.

The meaning of EXPORT_SYMBOL_INTERNAL is that it can be used to export symbols by base kernel subsystems (static or modular) to other base kernel subsystems which can be compiled as a module. So, if the symbol is thus exported by what is thought of as "base kernel" then only modules that claim to be "base kernel" should use it. Similarly, if it is exported by a driver, then only modules closely associated with that driver (for drivers split in multiple modules) should be able to use it.

In other words, exporting symbols should not be based on the consumer's license because that is technically inappropriate criterion.

As for implementation, perhaps EXPORT_SYMBOL_INTERNAL could look like:

EXPORT_SYMBOL_INTERNAL(runqueue_lock, "scheduler");

and the corresponding module that implements a "scheduler" can claim its rights by:

MODULE_CLASS("scheduler");

A module should be able to belong to multiple classes, of course, i.e. it could provide both "scheduler" to get runqueue_lock and "filesystem" to get register_filesystem().

So, modutils would check module's classes and resolve or deny the corresponding symbol. And EXPORT_SYMBOL(sym) would mean "disable class check by modutils for this symbol".

I am not suggesting to throw away MODULE_LICENSE from .modinfo, only that it should have nothing to do with exporting symbols (i.e. it should be like author/description etc fields).

Now, all the above does not look like 2.4 matter, it should probably be implemented in 2.5. As for 2.4 perhaps it should be a simple matter of changing the actual name EXPORT_SYMBOL_GPL to EXPORT_SYMBOL_INTERNAL which would place INTERNAL_ instead of GPLONLY_ in .kstrtab. And the thing that would link with it in the module should not be MODULE_LICENSE but be a new macro:

MODULE_SYMBOLS_INTERNAL;

A module that doesn't make any special claims (for compatibility) gets only those exported by EXPORT_SYMBOL, whilst a module that claims access to MODULE_SYMBOLS_INTERNAL gets also those exported by EXPORT_SYMBOL_INTERNAL.

There should be no "licensing implications" but simply the (documented) fact that if a proprietary module writer is stupid enough to make a MODULE_SYMBOLS_INTERNAL claim his module will break far more often both with respect to existence _and_ semantics/implemention of those entries exported only "internally". But that is their own problem -- we should neither help them nor prevent them from doing their work and earning their living. That is my opinion. If the vendor has so many resources to spend on monitoring Linux kernel development (and therefore inevitably getting involved and _helping_ with it!) to stay uptodate with every implementation of internal symbols, then that is fine -- so much the better for Linux. But if they want to write stable and maintainable modules then they will never put MODULE_SYMBOLS_INTERNALS. We should be always convincing proprietary software writers by our technical superiority rather than by making their lives tough based on a whim of whoever chooses which license to allow exporting his symbol to.

Simple, ethical and makes everyone happy, or, at least those who understand that the design of a Unix-like operating system should be driven by technical superiority rather than by using marketroid's weapons against them (he who lifts up the sword shall fall by the sword).

Arjan van de Ven felt this would be over-kill, and Alan also said to Tigran, "Using any internals of the Linux kernel has licensing implications." And, "why are you trying to put me out of business by allowing people to use my code in ways the GPL doesn't permit. That cuts both ways." Tigran replied:

That would be the case _only_ under yet another interpretation of GPL. Strange thing about GPL is that there are so many interpretations to choose from :)

It is your interpretation that matters, not mine, so how can I convince you? But I am entitled to an opinion that your interpretation is, in some sense, wrong. Namely, in the sense that it is inconsistent with the similar situation in the case of libraries or even system calls. I don't see why exporting kernel symbols should be so radically different and extremely sensitive to the nature of the consumer's license for some symbols but not for others...

Ingo replied:

Tigran, the difference is very very fundamental, please think about it, and please try to ignore the fact that you are working for Veritas. Internal modules of the GPL kernel are just a technical modularization of a complete and unified GPL-ed work. We want it to stay consistent, we want *our* work to be fully and completely debuggable, supportable and we want to be able to understand and develop any part of it. This is our intent.

the moment you start to argue 'but why cannot we just add this set of EXPORTs and put our binary-only modules here and there' you are in essence questioning our freedom to specify the license of our work. You are abusing the internal modularization mechanizm to put in code that we cannot debug, cannot read and cannot develop and cannot support in any reasonable way. It's like exchanging kernel/sched.o with your binary-only implementation and not publishing the source code of it. If you want to play such games then you have to implement the other 4 million lines as well, nobody prevents you to do that.

system calls are a published, honored, maintained interface. User-space applications are indpendent works not derived from the GPL-ed kernel in any way. Hence the exception.

historically we have also chosen to to provide a different type of API towards more or less clearly separate works, like independently developed, non-GPL hardware drivers. Let yourself not be confused by the fact that the same technical mechanizm is also used to demand-link separate smaller parts of the kernel work as well.

The impact of binary-only modules on the kernel's development architecture is not zero but not overly significant either, so most of us are pretty pragmatic about that, as long as binary-only module vendors are not abusing this mechanizm to impact the integrity of the kernel and create clearly derived works without obeying the rules of the GPL. And it's clear that internal symbols are just that: internal, still part of the kernel work. [and directly resulting from that, they obey the GPL.]

I consider 'abuse' for example a kernel derivative with a 'modified' scheduler. The day it will be possible to put a binary-only sched.o into the kernel i'll stop doing Linux. I am not here to develop some 'lite' version of the OS, where all the interesting stuff happens behind closed doors. I'm not here either to see the quality of the OS degrade due to sloppy programming in widely used binary-only modules, without being able to fix it.

The GPL right now protects our work from being abused in such a way - it's illegal to provide a binary-only sched.o and compile a kernel product from that, because the resulting kernel is still one work and the whole work must still be under the GPL. It's equally illegal to recover the location of sched.o in the final kernel image and runtime relink it with a binary-only sched.o. It's equally illegal to accomplish the same over the internal module interface.

Think about it, every separate .o in the Linux kernel can be equivalently expressed in terms of a EXPORT-ed module interface, GPL-ed header files and a closed-source module. There is a good reason why the GPL forbids such freely defined 'module interfaces' to be added. Think of the GPL as the price you pay for being able to use the Linux kernel's source code or being allowed to link to it - you are not forced in any way to do that.

and no, you have no *right* to link a binary-only sched.o to the Linux kernel - even if you develop a sched.c 'separately' - and intuitively feel that it's somehow a separate work, the end result is still a derivative of the kernel. And this violation of the license is illegal in most countries, it's even a crime in some countries.

Tigran replied:

After thinking about it for a while (and careful reading of your explanation) I must conclude that your view is probably safer, i.e. in the long term it is probably better for the Linux kernel to protect its status along the lines you described, even if it is not as "smooth" or "convenient to everyone" as the scheme I was talking about.

On the issue of what should be considered a derivative and what shouldn't, from your email it seems (and it's not a bad thing, imho) that the Linux kernel is protecting itself to make sure that "interesting" functionality is either already in the kernel or exists as a GPL'd module.

To make this thought clearer, let's say that there is no GPL'd journalling filesystem for Linux (i.e. reiserfs, ext3 and others suddenly disappeared). Then, to make your thoughts consistent you would need to disable the exported interfaces required for development of a journalling filesystem. Because, otherwise, you would be working on a "lite" OS and "interesting stuff will happen behind the closed doors". As I said, it is not necesserily "bad", i.e. it may well be necessary for Linux's survival and therefore I am all for it. I only thought that there is something _technically_ unpleasant or "wrong" about it... Maybe "wrong" is the wrong word, but you know what I mean.

3. New fbdev API

3 Apr 2002 - 4 Apr 2002 (4 posts) Archive Link: "[PATCH] new fbdev api."

Topics: Framebuffer

People: James SimmonsDave JonesGeert Uytterhoeven

James Simmons said, "This patch is the first in a series to move over to the new fbdev api. It is against 2.5.7. The basic goal is remove the tones of redundent code in the fbdev layer and make a much simpler api. The main way to accomplish this is to reverse the flow of logic for the console system. The fbdev system was later developed and we see alot of needless functionality added to the fbdev layer. Instead the flow should be functionality in the console system to the fbdev layer instead of the reverse. Also accomplished is the seperation of the fbdev layer from the console layer. This will have a very important impact on linux embedded devices. It has been tested and has been in Dave Jones tree for some time. Geert with your blessing I like to have it added to Linus tree." Geert Uytterhoeven gave his blessing, and Dave Jones added, "Indeed, the fb changes are the largest chunk of -dj right now. The three heavy-weight patches pending integration by their maintainers make up for half of whats left to be resynced.." And James replied, "I have more too :-/ I'm breaking it up as much as possible. I also have a few more changes/fixes to send your way but I'm going to wait for that."

4. BitKeeper Statistics

3 Apr 2002 - 6 Apr 2002 (23 posts) Archive Link: "Linux-2.5.8-pre1"

Topics: Version Control

People: Larry McVoyLinus TorvaldsDave JonesMatt Domsch

Linus Torvalds announced a "largish" 2.5.8-pre1 patch, and Larry McVoy pushed it to bkbits.net (http://linux.bkbits.net:8080/linux-2.5/stats) . He said, "Largish is right. 1200 deltas." And added, "You can click on any name to see what they have been working on, once you drill down through a name, you are looking at things through a "this user only" filter." Linus replied:

Side note: this only works partially.

For example, of the 297 changesets in 2.5.8-pre1, 147 were from email patches (the 50% ratio seems to have held up pretty well over time: about half of the submissions I get are old-style patches, with half being BK merges. Of course, for me the advantage of BK is that the BK merge half often required _much_ less than 50% of the time).

Anyway: of the 147 patches, 125 were merges from Dave Jones (only 123 are marged as such - two were re-attributed by me by hand by editing the emails directly).

And of those 123 changesets marked as coming from Dave, most were obviously written by others, and Dave acted as integrator (which is not unimportant, of course - 99% of what I do myself is only integration these days).

So the statistics get skewed by details like this - if is only a partial map of who actually _wrote_ the patch.

(The same is sometimes true of the BK patches themselves, not just the email patches I get from integrators liek Dave who still use diffs to merge with me. It depends on who and how the original BK changeset was created, of course).

Dave Jones suggested, "If I stuck to a common way of marking the original author, you could probably enhance your merging scripts to suck that out and attribute $whoever instead." Larry came up with the same idea, and also replied to Linus, saying:

I think I see. If you get a GNU patch from someone like Dave who got it from someone else, then it shows up as Dave in your changelogs. Hmm. Do you think it is worthwhile to try and do some parsing of the message such that we can set $BK_USER to the right person if the message contains the info? Dave is pretty good about doing stuff like

Patch description...
Originally from Matt Domsch.

If we formalized that a bit we could get the annotations right. I know it may sound like an ego stroking exercise, but it's actually very useful when looking at the annotated history to see who did something, it makes it easier to track them down and feed them new changes/suggestions/etc. Yeah, it makes it easier to bug them with questions too, but that tends to happen anyway.

There was no reply to the idea.

5. BitMover Reports On BitKeeper

4 Apr 2002 (1 post) Archive Link: "2 months of BK"

Topics: Version Control

People: Larry McVoy

Larry McVoy reported:

Time flies. Just ran some stats in Linus' tree.

Linus created his tree on 2002-04-03 17:03:45-08:00.

3177 changesets (logical changes/patches/whatever you want to call them). 55000 deltas in 11832 files.

BitKeeper overhead for maintaining this information, the changeset stuff, is about 7MB uncompressed. It started at about 1.5MB for the initial baseline, so we're growing at about 3MB/month, which is a problem.

Since I'm typing, here's the set of things we're currently concerned with and working on for the Linux kernel tree:

  1. Performance of updates. The actual updates themselves are fairly fast but the integrity checks hurt. We've already released a new version which does less integrity checks if you turn on partial_check: yes in the config file.
  2. Space overhead. The design of the changeset data structures doesn't scale well enough and we know how to do better.
  3. LODs. We've been stewing on the discussions that occurred here on the whole "I want to have people test this so it needs to be in BK but then later I want it out of BK". We have a LOD design that makes that possible and also gives you named containers for each maintainer, cherry picking, etc.
  4. Nested repositories. This gives you the ability to chop up the kernel and have only the parts you actually need on your disk, that's the theory at least. We have commercial customers who really want this and I think it may be useful for the kernel as well.

Those are the main ones and that's enough to keep us busy for several months at least.

There was no reply.

6. DAC960 Troubles Under 2.4 Kernels

4 Apr 2002 - 5 Apr 2002 (5 posts) Archive Link: "2.4.x and DAC960 issues"

People: Marcelo Tosatti

Albert Max Lai reported that on his Tyan S1836DLUAN-BX, dual PIII 600Mhz, the DAC960 driver would hang, on any 2.4 kernel. With 2.2 kernels he had no problem. Marc A. Volovic replied that he'd been having complete success with this driver under 2.4 on his dual 550MHz MSI 6120S. He suspected Albert's system was doing bad things with interrupts, and asked Albert to post his /proc/interrupts file. Marc had some questions about this, but took them off-list. Marcelo Tosatti also said, "I've forwarded your first message to Leonard (the driver author)... well probably get some feedback soon." But there was no reply.

7. 2.4 Kernel Recommendations For SPARC Systems

5 Apr 2002 - 7 Apr 2002 (3 posts) Archive Link: "Best 2.4 kernel for SPARC?"

Topics: Preferred Kernel Version, SMP, Virtual Memory

People: Sean NeakumsLuigi Genoni

Martin Eriksson asked which 2.4 kernel ran best on SPARC machines, specifically a SPARC Ultra 10 3D creator with RedHat 6.2; Sean Neakums replied, "I've been using mainline 2.4.18 plus rmap12h on my Ultra5 successfully for a few weeks now. Built with Debian's egcs64 package, which is version 1.1.2, as I recall. It's been very solid; no problems at all." And Luigi Genoni also said, "I am using 2.4.18 without problems on ultra2, ultra5 ultra10 E280 E420, so I tested both mono CPU and SMP (till 4 CPUs) systems. on the ultra2 SMP I tested also the peemptive kernel patch. So I think you can be quite sure with latest 2.4 kernels. Another thing is 2.5 kernels, I was not able to use many of them on sparc."

8. Status Of O(1) Scheduler Patch

9 Apr 2002 - 10 Apr 2002 (9 posts) Archive Link: "0(1)-patch, where did it go?"

Topics: Big O Notation, Scheduler

People: Dieter NützelJ.A. MagallonIngo MolnarJoe Sloan

Someone asked whatever happened to Ingo's O(1) scheduler patch. Was it in 2.4.19? 2.5.x? Where? Joe Sloan said it had gone into 2.5, and the -ac patches to the 2.4 tree. J.A. Magallon also pointed out that the latest version could be found at http://giga.cps.unizar.es/~magallon/linux/kernel/. Dieter Nützel pointed out, "Didn't you noticed any of the reports about very bad numbers for latency since Ingo's latest 2.4.17-K3 version? Even Alan's tree show the same (latest I've checked was 2.4.19-pre2-ac2)." He added, "We do need some words from Ingo first. He haven't answered my posts since February ;-(" . He thought he might have the wrong email address for Ingo Molnar, but Peter Kelemen confirmed that Dieter had the correct address.

9. Status Of ext2 Maintainership

11 Apr 2002 (3 posts) Archive Link: "Possible EXT2 File System Corruption in Kernel 2.4"

Topics: CREDITS File, FS: ext2, MAINTAINERS File, Maintainership

People: Frank KraussAndreas DilgerAndrew Morton

Frank Krauss experienced an ext2 problem, and said, "I attempted originally to send this information to Remy Card as per the MAINTAINERS file at RemyCard@linux.org but I got the message about him being an unknown user." Andreas Dilger posted a patch, saying, "This is a patch (after I don't know how many years of him not working on it) to remove Remy Card as ext2 maintainer. Since I'm not comfortable adding other people's names as maintainers (and I don't think Linus/Marcello/Alan would accept that anyways), I've just put the ext2-devel mailing list. All of the ext2 developers are on it." Andrew Morton replied, "Yes, I'd support that. It's a sad thing to do, but there is no point in misleading people in this way. Remy already has an entry in ./CREDITS for ext2."

10. Measuring Time Spent In The Kernel

11 Apr 2002 (3 posts) Archive Link: "measuring time spent in kernel"

Topics: Profiling

People: Karim YaghmourTorrey HoffmanAndrew Morton

Torrey Hoffman pointed out that tools like top didn't report the amount of time spent in the kernel. He'd heard of a tool that used up as many cycles as possible in order to accurately gauge system time, but he couldn't seem to find such a thing in his Googling. Karim Yaghmour suggested, "You may want to try LTT: http://www.opersys.com/LTT. It will give this sort of information, among many other things, and it doesn't soak up any cycles." And Andrew Morton also gave a link to a Google search for cyclesoak (http://www.google.com/keyword/keyword/%3Fcyclesoak) . There was no reply.

11. Status Of Highmem Patch In 2.4

11 Apr 2002 (3 posts) Archive Link: "[patch 2.5.8] bounce/swap stats"

Topics: Big Memory Support

People: Randy DunlapMarcelo TosattiJens Axboe

Randy Dunlap posted a patch and said, "I'll generate the patch for 2.4.teens + highmem if anyone is interested in it, or after highmem is merged into 2.4. ...it will be added to 2.4, right?" Marcelo Tosatti replied, "highmem IO will be merged in 2.4.20pre1." And Jens Axboe replied, "Thanks Marcelo, I'll personally polish a version for you once 2.4.19 final is out."

 

 

 

 

 

 

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.