Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||26 Apr 1999 - 5 May 1999||(30 posts)||/proc Discussion|
|2.||30 Apr 1999 - 6 May 1999||(5 posts)||Raw I/O Under Linux And FreeBSD|
|3.||30 Apr 1999 - 5 May 1999||(16 posts)||Linux Criticized In Windows NT Magazine|
|4.||1 May 1999 - 2 May 1999||(4 posts)||MTRR In The Main Tree|
|5.||2 May 1999 - 8 Feb 1999||(11 posts)||Philosophy Of Open Source; Maintainer Conflict|
|6.||2 May 1999 - 4 May 1999||(8 posts)||Memory Map Problems Interfering With CD Recording|
|7.||2 May 1999 - 5 Feb 1999||(7 posts)||Development Conflicts And Resolution|
|8.||2 May 1999 - 7 May 1999||(29 posts)||Alan Cox Recommends Trident's GPLed ALSA Drivers|
|9.||5 May 1999 - 6 May 1999||(6 posts)||Developer Conflicts|
Sorry about the delay this week. It wasn't computer problems this time (whew!), just a little busy with other stuff at the moment.
Well, we've reached the end of the calm, gentle, stable kernel series. For the foreseeable future it is raw flesh and the taste of blood all the way. But don't expect any of it in this issue of KT. All the new 2.3 threads are still ongoing.
Mailing List Stats For This Week
We looked at 1086 posts in 4279K.
There were 427 different contributors. 177 posted more than once. 136 posted last week too.
The top posters of the week were:
1. /proc Discussion
26 Apr 1999 - 5 May 1999 (30 posts) Archive Link: "sed not working on /proc files"
People: Ralf Baechle, Richard B. Johnson, Stephen C. Tweedie, Alan Cox, David Woodhouse, Simon Richter, Chip Salzenberg, Stefan Monnier, Jeremy Fitzhardinge
Stefan Monnier discovered that running sed directly on /proc files produced no output at all, while catting the files and piping them through sed worked fine. Richard B. Johnson explained that /proc files have zero length, so when sed uses lseek() to read into the file, it finds nothing to process; and that when catting through a pipe, lseek() returns ESPIPE, which tells it the data is part of a pipe, socket, or FIFO. However, Stefan did an strace on sed and found that it wasn't using lseek(), though it did do an fstat(). Richard replied that fstat() did the same thing, and Ralf Baechle pointed out that, "optimizing this useless lseek(2) away was one of the libc changes during the last ages."
Jeremy Fitzhardinge also noticed the fstat() situation; and in that branch of the thread, Richard said, "I understand that the reason why most sizes are not reported are that sizes are dynamic, i.e., /proc/interrupts is bigger each time a value increase over 10. Since the /proc file-system does know when a directory access is made, it might be a good idea to actually calculate the length (but only at directory access time, not when data are being accumumated which would be a large overhead that is wasted because /proc is seldom read." He also made the odd suggestion, "It is also possible to just return a size of, maybe, 1024 bytes for each of the files that are normally 0 size. I don't think a premature EOF would affect most Unix tools. This would have zero overhead and might make life easier." He did a patch and reported success: EOF didn't interfere with things like sed and less. A number of people strongly objected that the idea was ugly and broken, and that the problems it solved had easy workarounds anyway.
Rafal Maszkowski suggested that /proc files could masquerade as pipes, and asked if this would spoil anything. Stephen C. Tweedie replied, "It would spoil the kernel: the kernel works very hard to make sure that even when you have different filesystem types present, the pipe and socket code is all handled by common code, not by the particular filesystem involved. You'd have to break that abstraction to give pipes special meaning inside /proc."
Elsewhere, Chip Salzenberg asked if it would be bad for mmap() to fail on /proc files that don't report true sizes, and Stephen replied, "We don't need to support mmap for /proc at all. In fact, according to mmap semantics, we can't: there is no permanent memory reserved for /proc at all." Simon Richter complained that this broke libc file accesses, and Alan Cox said that relying on mmap() being available was broken (though he acknowledged it was the kernel's fault for treating 0 length mmap()s as succeeding). Some folks suggested changing that behavior, and David Woodhouse posted a patch so mmap() wouldn't return success on 0 length mmap()s.
Don't know exactly what the upshot of all this is. I know there's a lot of criticism of /proc in general, so this could be the memes working out. WIUM.
2. Raw I/O Under Linux And FreeBSD
30 Apr 1999 - 6 May 1999 (5 posts) Archive Link: "Porting Greg Lehey's rawio.c from FreeBSD to Linux..."
Topics: BSD: FreeBSD, Raw IO
People: Alan Cox, Stephen Tweedie
Brad Knowles wanted to do some low-level disk benchmarking, so he was trying to port rawio to Linux. He needed this raw access, to make sure his benchmarks weren't polluted by any intermediary code layer, and wanted to know if anyone had experience porting those kind of programs. There was no reply for 4 days, but then Alan Cox explained, "the notion of 'raw' disk is foreign to Linux. Its a Unixism. The block device interface is used instead. That isnt optimised for performance however (ie heavy readahead etc)." He suggested, "if you want to get an accurate disk/controller benchmark you might want to get Stephen Tweedie's O_DIRECT patches (ftp://ftp.linux.org.uk/pub/linux/sct/) which give you what are logically the same thing - uncached I/O from the disk itself," and offered as warning, "my only concern is that if FreeBSD does do a copy through kernel space for its raw devices you may not be making an appropriate comparison benchmark for some things as Linux would be going userspace->media."
Brad replied that the situation effectively prevented all but kernel hackers from tuning Linux or even performing good benchmarks; but Alan didn't think it was that big a deal, and pointed to Stephen's patches again.
3. Linux Criticized In Windows NT Magazine
30 Apr 1999 - 5 May 1999 (16 posts) Archive Link: "[OT] Comments to WinNT Mag !!"
People: Nick Brown, Alan Cox, Ingo Molnar
Mark Russinovich wrote an article in Windows NT Magazine, and there was some response on linux-kernel. Mark even participated a little (1 post).
There were some comments about Mark from people who'd spoken with him directly. Nick Brown said, "I have corresponded briefly with Mark Russinovich on NT-related issues in the past, and he has always seemed a very fair-minded individual. He certainly isn't in Microsoft's pocket, for example." Alan Cox said, "I've had several discussions with him. He avoids questions about points that don't fit his pet theory of OS design, he criticises anything that doesn't follow his theory and often doesnt seem to understand it." Ingo Molnar, at the end of a rebuttal to Mark's article (see below), said, "in private discussions with Mark i have pointed out most of these counter-arguments, which he unfortunately failed to answer. He also didnt answer my questions about NT's shortcomings."
Ingo rebutted Mark's article, and Shane R. Stixrud sent the rebuttal to Mark, who replied under the Subject: Mark Russinovich's reponse Was: [OT] Comments to WinNT Mag !! (fwd); then Ingo replied to that. Their replies were long, and difficult to merge into a KT-style discussion. I'll just give the links to Ingo's first rebuttal, Mark's response (as forwarded by Shane R. Stixrud), and Ingo's reply to that. There followed quite a bit of technical discussion of the various issues raised.
4. MTRR In The Main Tree
1 May 1999 - 2 May 1999 (4 posts) Archive Link: "K6 and mtrr support"
People: Richard Gooch, Riley Williams, Linus Torvalds
W. Michael Petullo was impatient for the K6 mtrr support patches to get merged into the Linus Torvalds tree, since they've been in the ac series for awhile and seem to have no problem. Matthew Vanecek also felt it was about time. He'd had no problems at all with the patch, and asked if there was any special reason Linus was holding off applying it. Richard Gooch replied, "The MTRR support for AMD has been integrated into my MTRR patch (which includes Cyrix/IBM support), and has been submitted to Linus. I've not heard back from him yet," and Riley Williams pointed out that Linus had recently been on vacation and at Comdex, which might explain the delay.
5. Philosophy Of Open Source; Maintainer Conflict
2 May 1999 - 8 Feb 1999 (11 posts) Archive Link: "[OT] util-linux-2.9p"
Topics: Ioctls, Maintainership, Modems
People: Andries Brouwer, Andrea Arcangeli, Michael K. Johnson, Theodore Y. Ts'o, Victor Khimenko, Rogier Wolff
Andries Brouwer announced his release of util-linux-2.9p; in the course of discussion it came up that Andrea Arcangeli had taken development of tunelp over from Michael K. Johnson. When Andries heard this he said, "Somewhat surprising, but if Michael Johnson has no objections and Andrea says he really wants, I'll take tunelp out of util-linux."
Michael and Andrea both replied to this. Andrea said:
For the tunelp maintainer issue, the problem is that tunelp was obsolete. On linux-parport we was thinking to update it since 2.2.0 was near. I asked on linux-kernel if somebody would send me the sources of tunelp. Then a guy sent me the uuencoded tarball. So I updated tunelp and then I put the new tunelp here -> ftp://e-mind.com/pub/andrea/tunelp/. Tim correct me if I remember wrong. Ah and then I also sent to Alan (when Linus was in holiday) the update of my tunelp in the Changes file.
Then Michael claimed to be the maintainer. I am _far_ from want to be the maintainer if _he_ was the maintainer.
The reason I am been the guy who updated tunelp (and I did that mainly for the end user, not for mine, I had just the manpage updated in my mind ;) is been because I known all 2.2.x lp details (I researched, learn and developed most of them).
If he want to return to be the maintainer of tunelp I would be very happy. He can merge my code at any time in his tree and go ahead. Otherwise let me know.
Michael's response to Andries (probably without knowledge of Andrea's) was:
I never handed over maintenance of tunelp to anyone else. No one, certainly not Andrea, ever asked me. No one ever, EVER, sent me a patch regarding the changes in the 2.2 kernel. I complained to Andrea about this some months ago and he got really huffy about it and basically told me to go away and not bother him about it.
It doesn't bother me to take tunelp out of util-linux (indeed, I suggested it some years ago based on the fact that I (yes, *I*) was maintaining it). It only bothers me that Andrea took it over in the most impolite way possible -- doing so without contacting the original author, and telling the original author where to go when contacted about that impolite behavior.
Andrea replied to this, saying he hadn't realized there was a maintainer, and no one on the linux-parport mailing list had claimed it, and he couldn't find any official ftp site; so he'd just assumed there was no one to contact about taking it over. He said Michael was welcome to merge Andrea's changes into his tree, and he objected that he wouldn't have told Michael to go away when Michael contacted him, because he would have been happy not to have to maintain tunelp.
Michael came back, saying that he'd been listed as the maintainer in the package itself. He added that rather than having to merge Andrea's changes in himself, it would be polite for Andrea to send him patches; he also said Andrea was welcome to become the maintainer if he would just ask. As a statement of principle, he said, "I didn't mean to bring this up again. I would keep it private except that it's a general reminder to folks -- please, it's polite not to take things over without making at least some attempt to contact the original author, EVEN IF YOU DON'T FEEL THAT THEY ARE VERY ACTIVE. This software is GPL-licensed, so you are within your rights. However, we are still a community that is built on trust, and ripping people's pet projects away from them without so much as a by-your-leave tears down that trust."
Andries agreed, and felt there was plenty of evidence in the tunelp package for Andrea to be able to find the maintainer. He added, "It is a very bad habit to take over software without inquiring where it comes from. Not only is it impolite, but it also leads to inefficiency and splits. (As Werner remarked: now we have a tunelp that is willing to talk German, French and Brazilian, and we have a tunelp that knows about the TRUSTIRQ ioctl - nobody is happy with such a split.)"
(As an aside, he offered this disturbing tidbit, "By pure coincidence I complained less than a week ago to these rascals at RedHat - they never send me patch and motivation regarding the changes they make in the stuff I maintain." )
Andrea was also getting a little annoyed, and said:
One of the basic property of GPL licence is to allow everybody to fork a GPL'd tree. So forking a GPL tree (as far as you won't break GPL because you left the copyright holder of the author, you won't link with no-GPL source as in the past KDE issue, etc..etc..) is _not_ a bad thing. If you don't like my behaviour is better that you start using a different licence for your code instead of complain. Since it was faster for me to take over instead of searching and then contacting the author (and as just said I was thinking that tunelp wasn't maintained anymore) I taken this faster way.
Before taking this way I spent 10 minutes searching on the network the official tunelp sources. The manpage doesn't mention Michael as the mantainer and I couldn't find the official ftp site for the sources (try with a man tunelp and you'll see how many info you get). And since I pay for the phone while I am connected to internet I stopped searching and I taken the _far_ faster and simpler unpolite path (and once the unpolite path is been started the only objective become the real work). I would redo the same now if I would be in the same context.
If the next time I'll be in a similar condition, you'll pay for the more time I should spend to take the polite path (for the phone to connect via modem etc..etc..) with _your_ money (instead of with the money of my parents), then, _only_ in such case, I'll be polite. Otherwise no-way and _stop_ complaining.
Now according to me the right thing to do is to merge my work on the official tree and then to delete my tunelp from my ftp area. But I am not going to send patches in my spare time because I just want to do other things in my spare time.
I would like if you would merge my tree in the official tunelp yourself, otherwise ignore me.
Under the Subject: Maintainers, there was an interesting discussion of Open Source politeness in general (see below). But at one point, Michael added, "This whole thing is way overblown, and I didn't mean to make a huge deal of it. tunelp is, by design, a small program. I'm not unwilling to consider handing it off if that's appropriate. The only reason I keep talking about this is that I'm worried about a general uncooperative spirit here damaging the whole community. I can lick my wounds and shut up -- that's what I did for months until the problem was brought up by someone else and my opinion asked..."
Elsewhere, Theodore Y. Ts'o said to Andrea (in response to Andrea saying, "I _hope_ to be still allowed to choose what to do in my spare time." ):
You certainly have the right to do so. However, not dropping Michael a note when his name was clearly listed in the sources was indeed very rude. Your further claims about how you can't be expected to search the entire web looking for the maintainer, and ignoring the fact that his name and copyright were on the sources --- and that maybe, JUST MAYBE, he was the maintainer --- wasn't rude per se, but it was lame.
No one is claiming that what you did was somehow illegal; however, what you did did contradict the general customs of our electronic society. You can choose to be antisocial if you wish, but then you have no right to complain when people choose to call you antisocial.
That being said, it sounds like you might have a legitimate beef if you think that Michael hasn't been a responsive maintainer. If that were the case, the right thing to have done was to send a private note to him asking what the status was. If you had done that, he might very well have given the maintainership over to you, and that would have been that. If you then don't get a response from the maintainer, it would have been appropriate to send an e-mail message to the list asking about who the maintainer was, and so on. But there are a set of customs that you have to follow if you don't want people to think you are a loser.
These customs have been informally codified and people have lived by them for a very long time. More recently, Eric Raymond has done a fairly good job of formally describing them, if you're not already familiar with them; please read Homesteading the Noosphere if you want to see a treatment of these customs from the point of view of a net.anthropologist.
The main thing, though, is that courtesy is really good thing for everyone. So may I suggest that we just drop this. Let's assume that Andrea simply didn't understand the rules and accidentally transgressed them without meaning to hurt anyone, and let's move on. We're all trying to work together, remember? Let's remember who the real enemy is; this in-fighting serves no purpose.
About politeness in general, Victor Khimenko said:
I'll try to summarize discussion.
Forking of any software (GPL'd or not) is REALLY BAD THING. This is undisputable. (Take a look on Unix -- it's not GPL's code but idea is the same).
Now, why GPL allows it in first place ? Simple:
Forking of tree is not the worstest thing in the universe and if it's needed to solve more important problem this is exactly what's must be done.
Which problems are worse then forking (or probability of forking) ? One of them:
If software in not actively maintained and bugfixes or important improvements are not made public for long time then someone must step up and take maintainership. Aven if this will lead to risk of forking.
If working e-mail address of "official mantainer" (and/or primary author or software if in sources or documentation not written that you should not bother original authors anymore -- GIMP is example) is known then at least e-mail with explanation should be sent: mantainer can be just temporarily unable to actively mantain util/patch/whatever (I was in hospital for almost the whole April and I was clearly unable to mantain my alternative version of mod_ssl's EAPI)"
Rogier Wolff gave his opinion:
As a maintainer, you should mark the sources with your Email address. That way people can contact you when they find a bug.
As "someone who has found a bug" you are expected to contact the maintainer by Email. If you don't get a reply in a week, it is appropriate to perform a quick "who's where" or "bigfoot" search, to see if this Email address has become stale. If a week later there still isn't any answer, it becomes appropriate to post the patch together with a remark like "Does anybody know where .... went?"
When that doesn't turn up an active maintainer, I guess you're welcome to take over.
6. Memory Map Problems Interfering With CD Recording
2 May 1999 - 4 May 1999 (8 posts) Archive Link: "Memory problems"
People: Victor Khimenko, Martin Schulz, Rik van Riel
Martin Schulze pointed out mmap problems that were interfering with his CD recordings. Victor Khimenko replied, "Yes. It's VERY WELL known problem with linux MM :-(( Unfortunatelly right solution will need deep rework of MM subsystem since now there are NO reliable way to get contigous DMA-able region of memory > 4K (page). There are some ideas floating around about possible solutions but it's not clear even if it's 2.3 issue. It's not 2.2 issue for sure :-(( There are exists some more or less reliable workarounds (load all modules like floppy or sound modules on startup; `tail /dev/zero, etc) but there are no general solution yet (AFAIK anyway)." Rik van Riel pointed to a zone allocator he designed, and also said the discussion really belonged on the linux-mm list (Linux-MM@kvack.org).
7. Development Conflicts And Resolution
2 May 1999 - 5 Feb 1999 (7 posts) Archive Link: "[PATCH] Minor cleanup/fix in quota_on()."
Topics: Developer Interaction
People: Jan Kara, Alexander Viro, Linus Torvalds
Alexander Viro and Jan Kara discovered they'd been working on the same code, and their patches were colliding. They both agreed the patches would be trivial to merge, so Jan did it, put the results on the web, and submitted them to Linus Torvalds.
8. Alan Cox Recommends Trident's GPLed ALSA Drivers
2 May 1999 - 7 May 1999 (29 posts) Archive Link: "[OT] SB Live! drivers released for Linux"
Topics: Sound: ALSA, Sound: SoundBlaster
People: Alan Cox, Aaron Tiensivu
Aaron Tiensivu was very happy to find these drivers, but Chris Adams pointed out they were only binary releases (thus not guaranteed to work from kernel to kernel, and not maintained as well as Open Source). Some folks took the attitude, "better binary than nothing," and there was the suggestion of reverse engineering to derive an Open Source project. Ladislav Dobias suggested the Yamaha WF192XG which also has a driver for Linux, but Alan Cox said that it, too, was binary only.
Alan said Trident was putting its ALSA drivers on the GPL (making them his top recommendation), and that he hoped to get the ESS maestro/maestro2/maestro2e mostly working.
9. Developer Conflicts
5 May 1999 - 6 May 1999 (6 posts) Archive Link: "Status of Linux SCSI generic implementation"
Topics: Disks: SCSI
People: Douglas Gilbert, David Mosberger
Someone gave a pointer to Jörg Schilling's page on SCSI generic implementation, as well as a discussion of the competing interfaces. A restrained Douglas Gilbert replied:
The new implementation is in place and working in 2.2.6 and 2.2.7 with some blemishes to be ironed out in a new patch hopefully to be ready for 2.2.8 (it's with ac now). The interface is just the tip of the iceberg. It will not change.
The driver has been accepted by David Mosberger-Tang (sane) and Monty (cdparanoia) as a reasonable (but not necessarily the best) compromise. Monty has a cdparanoia III alpha that uses some of the new features. Various other developers (some working for big corporations) seem to be happy with the progress.
Joerg Schilling holds out with his own interface on top of my implementation. He conveniently neglects to mention that he has borrowed about 1200 lines of my code which I continue to maintain. The problem with this is the bug fixes + minor implementation improvements that have been added in the last 7 weeks (since he forked the code). Hopefully with time he will either drop this approach of use run time selection in his transport library to support both (and I have supplied such a patch).
It seems as though some people want this debate re-opened and I will shortly make a posting to the linux-scsi list which seems like the correct place. That post will challenge most of the technical claims made in the above documents which I ignored in the forlorn hope that Joerg would, in time, relent. I will do my best to ignore the personal accusations.
As of KT press time, the promised post has not appeared in the linux-scsi archives.
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.