Kernel Traffic #18 For 13 May 1999

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.

There were 427 different contributors. 177 posted more than once. 136 posted last week too.

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.

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.

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."

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.

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."

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.

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." )

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.

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)"

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.

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).

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.

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.

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.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

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

Kernel Traffic #18 For 13 May 1999

By Zack Brown