Date: Thu, 12 Jun 2003 00:42:41 -0400 From: damien taylor To: rasmus@lerdorf.com Subject: PHP Dear Rasmus, I want you to know that I have checked out your "open source project", and I feel it necessary to inform you that even though you hide behind the guise of "open source", what you produce is total crap. Having attained a Phd in computer science, I can assure you that you are not fit to write a single line of code or be involved in any sort of open source project. After causing multiple crashes and being generally useless, I want to let you know that you are doing a great disservice to the open source community, and the open source movement in general, by passing off your "work" (if you can call it that) as anything other than totally useless. As much time as I have spent ridding my machines of your bug-ridden "work", I will now dedicate towards making others aware of the awful crap you produce. Be warned, your fraud will soon be exposed. Good luck, next time please at least take the time to research your basics, and maybe get a little smarter, before pushing this absolute crap on the public. I look forward to the future of an open source movement that will be much better off with you flipping burgers instead of writing code at a kindergarted level. Please please do something else with your time other than discredit the open source community with this drivel. Leave it to those who can comprehend it. Walter Bagdasarian ================================================================ From: Bryan Cantrill (bmc@kiowa.eng.sun.com) Subject: Re: But why? Newsgroups: comp.sys.sun.hardware Date: 1996/10/29 In article <54990q$n5e@caip.rutgers.edu>, David S. Miller wrote: >bacon@mtu.edu (Jeff Bacon) writes: > >Since I have been able to find an intelligent posting in this thread, >I will respond to it and explain what I can as chief architect of the >SparcLinux port. > >> of course, then, the obvious question that comes up is WHY is it that >> solaris has such higher overhead costs in doing things? >> >> obviously there's more code to work through to do any given thing. >> someone must have thought it necessary. but...why? >> >> obviously it's got lots of extra crud from SVR4. why not pitch it? >> > >The answer to this is pretty straight forward actually. The main >points of interest are: > >1) Solaris's networking stack, in all of it's incantations (one breed > of it was the Lochman code in 2.0, 2.1 and early 2.2 releases, then > it was rewritten by another company for 2.3 onward) is SVR4 streams > based. The performance penalty, even with lots of tricks, for > using a SVR4 streams networking architecture is well known. > Someone who happens to have a 2.2 Solaris CD around, or even a 2.3 > Solaris CD, should install that thing and run lmbench on it to see > what "pure Streams based networking" without the tricks can really > do. > > Linux on the other hand has a "no bullshit" networking architecture > that is not streams based. Yet we also take advantage of the many > known networking performance enhancements that exist in the > research realm (ie. copy/checksum, the van jacobson hacks, etc.) > >2) Linux is light weight, Solaris is a pig. > > One of the most critical things that contributes to performance > is cache/tlb footprint of the operating system. Linux being small > (yet still provide a full POSIX unix environment!) solves the cache > footprint problem in a big way. I've solved the TLB footprint > using Linux's small size and a Sparc specific trick. > > The MMU's present on the sun4m/sun4d line of Sun machines possess a > three level page table scheme. Using this, one has the capability > to use the normal 4k sizes pages, and also larger 256k and 16MB > sized pages. The average TLB on these machines has 32 or 64 > entries to cache these pte's, if the entry is not in the TLB > hardware has to go out to the memory bus and walk the software page > tables to "reload" the TLB so that the translation can be > satisfied. > > This "miss processing" is very expensive. Under SunOS and Solaris, > they do not take advantage of the 16MB and 256k sized pages to map > the operating system. Therefore those two systems take many misses > in the TLB during even the most rudimentary trap into the kernel. > However under Linux the TLB misses for the OS are quite minimal. > In fact I will gave an example: > > On your average SparcClassic with a 32 entry TLB, consider such > a machine with 24MB of memory installed. Under Linux I can map > the entire operating system (sans IO device register mappings > and Lance Ethernet DMA) in 3 (count 'em, 3!) TLB entries. These > 3 entries are enough to allow the kernel to access an arbitrary > physical page from kernel space. > > Under Solaris, the OS would need 3 + (24MB / 256K) + (24MB / 4K) > TLB entries to map this same amount of space. For a great many > number of operations, it is quite easy for an OS with this page > table strategy to blow the entire user context out of the > hardware TLB. Which in turn means more processor stalls (in > fact many) for both the user level processes and the operating > system. > > Result? Severe degradation in performance for the latter > scheme. > >3) Every BSD and SVR4 based system today, except for Linux, has a very > broken System call mechanism. > > You'd think that when people put together function call conventions > for a particular processor, the OS people would take a look at this > and find a way to take advantage of this. In fact, believe it or > not, they have not to this very day. > > Linux from day one, takes advantage of the procedure call > conventions on a particular architecture so that it can process > system calls in the most expediant way possible. I will give > an example on the Sparc to prove this: > > Consider your average 3 argument system call. The user level > code does something like this: > > mov %arg0, %o0 > mov %arg1, %o1 > mov %arg2, %o3 > mov SYSTEM_CALL_NUMBER, %g1 > t SYSCALL_TRAP > > At this point control reaches the operating system, it must > prepare to handle this request from the user. On the Sparc, this > is either a two step or a three step process depending upon > whether you are doing it in the traditional broken UNIX way or the > clean, fast, and superior Linux way. First I will show the Linux > method for doing this: > > 1) Step one, jump onto the kernel stack for this task > and make sure the kernel has a register window to > operate in safely. > > For Linux the code path for this runs at ~18 instructions > for the common case (the kernel already has a valid > register to use so now saving needs to be done). It runs > at ~42 instructions for the second most common case (the > kernels needs to allocate a new register window and the > user has a valid stack pointer) and ~82 instructions for > the least common case (kernel needs a window, user has > an invalid stack pointer, thus the kernel needs to save > the user's window into a special per-task save area). > > 2) Take the system call number, check for valid value, use > this to offset into a table of system call function ptrs. > Move arguments into place and perform the syscall. > > Basically this is a simple operations a looks something > like: > > sll %g1, 2, %l4 ! produce offset > ld [%l7 + %g1], %l7 ! syscall ptr base was in %l7 > SAVE_ALL ! perform step #1 above > mov %i0, %o0 > mov %i1, %o1 > mov %i2, %o2 > mov %i3, %o3 > mov %i4, %o4 > jmp %l7, %o7 > mov %i5, %o5 > > That is it, that is the entire system call under Linux. > > Under Solaris/SunOS things are wildly different. Step one is > basically the same, but step 2 is disgustingly inefficient for > those systems. Basically they do: > > 2) Call common system_call() C function. > > 3) This routine allocates a "system call argument package" > structure on the kernel stack. This is wasteful because > we already have all of this information in registers or > in guarenteed save areas. > > 4) Then this routine determines the function to call, and > passed this "package" of arguments to the routine. > > 5) Every system call which expects arguments then must > "unpack" this structure to get at the copy of the arguments > again highly inefficient. > > For every system call the system performs, you eat this unnecessary > overhead under SunOS/Solaris, under Linux only the bare minimum is > performed to do the system call successfully. > >4) Solaris cannot even do it's own optimizations correctly because > SunPRO is a broken compiler. > > I won't make such a statement without explaining this with real > facts, here goes. > > A neat part of the Sparc ABI is that it leaves you with a few > processor registers that the C compiler is not allowed to use > in the code it produces. Two of which are "%g6" and "%g7". > A problem in unix kernels is that you are constantly accessing > the current tasks control structure ('proc' and 'uarea' on > traditional UNIX's, the 'task_struct" under Linux). Hey, why > not put these pieces of information in those "extra" registers > and avoid the address computation all the time? Yes, very > brilliant idea. > > Under Solaris the trap entry code places the uarea and proc ptr > in %g6 and %g7. Under Linux the trap entry code places the > current processes task_struct in %g6. Now here comes where the > implementations differ. > > Under Solaris all of the so called "locore" (basically all the > gook which has to be written in raw assembly) code can directly > take advantage of this. However, the C code cannot do this > because SunPRO lacks a way for you to tell the compiler that > "hey you don't need to load things, it's already in these > hard coded registers" So they have the C code call these little > assembly stubs to get the values: > > get_uarea: > retl > mov %g6, %o0 > > get_proc: > retl > mov %g7, %o0 > > That is gross, why even do the optimization in the first place? > > Now GCC has a way to fully take advantage of such an optimization, > basically all I have to do is put the following in a header file. > > register struct task_struct *current asm("g6"); > > Tada, now GCC will fully understand what I have done for it. > Under SparcLinux this optimization alone took away 115 instructions > in the scheduler sources, and it took ~50 instructions out of the > exit() handling, and it took ~65 instructions out of the fork() > handling. > >So my question always is, in matters such as these. Who are these >processor cycles for anyways, the kernel or the user? Think about >this when you consider how much overhead is being saved from one OS to >another, and to what scale this is occurring. > >I hope that explains some of it, and gives people at least some sort >of idea of the kinds of things that makes Linux scream on just about >any hardware. If people would like more explainations like the above, >I'd be more than happy to chat with you via email about it or >similar. I love talking about performance issues on various >processors and systems. > >Oh, and one thing that has not been mentioned yet in this thread (and >yes NetBSD/OpenBSD both have this as well, good work guys). That >SparcLinux kernel that gets all of this incredible performance runs on >both sun4c and sun4m machines. Sun Engineers way back when scratched >their heads for months and couldn't figure out a way to pull it off >(you need a seperate kernel image depending upon whether you are >running on a sun4m or a sun4c, for SunOS/Solaris). And on top of that >Linux obviously pulls it off efficiently. > >One final note. When you have to deal with SunSOFT to report a bug, >how "important" do you have (ie. Fortune 500?) to be and how big of a >customer do you have to be (multi million dollar purchases?) to get >direct access to Sun's Engineers at Sun Quentin? With Linux, all you >have to do is send me or one of the other SparcLinux hackers an email >and we will attend to your bug in due time. We have too much pride in >our system to ignore you and not fix the bug. > >David S. Miller >davem@caip.rutgers.edu > Have you ever kissed a girl? - Bryan ---------------------------------------------------------------------- Bryan Cantrill, Solaris Performance. bmc@eng.sun.com (415) 786-3652 ================================================================ Linux 2.6.1, ipv6/netfilter/ip6t_limit.c: /* Check for overflow. */ if (r->burst == 0 || user2credits(r->avg * r->burst) < user2credits(r->avg)) { printk("Call rusty: overflow in ip6t_limit: %u/%u\n", r->avg, r->burst); return 0; } ================================================================ From: Rusty Russell <rusty@linuxcare.com.au> To: torvalds@transmeta.com, alan@lxorguk.ukuu.org.uk Subject: [PATCH] Trivial name typo. Date: Thu, 23 Dec 1999 15:24:07 +1100 Just noticed this... 2.2 and 2.3. This Russel disease must be stamped out before it becomes widespread. Rust. --- linux-2.2/net/core/dev.c.~1~ Sun Dec 5 13:24:45 1999 +++ linux-2.2/net/core/dev.c Thu Dec 23 15:20:21 1999 @@ -56,7 +56,7 @@ * Adam Sulmicki : Bug Fix : Network Device Unload * A network device unload needs to purge * the backlog queue. - * Paul Rusty Russel : SIOCSIFNAME + * Paul Rusty Russell : SIOCSIFNAME */ #include -- Hacking time. From: Linus Torvalds To: Rusty Russell cc: alan@lxorguk.ukuu.org.uk Subject: Re: [PATCH] Trivial name typo. Date: Wed, 22 Dec 1999 20:34:01 -0800 (PST) On Thu, 23 Dec 1999, Rusty Russell wrote: > > Just noticed this... 2.2 and 2.3. This Russel disease must be stamped > out before it becomes widespread. There's a serious shortage of the etter "", and we're trying to seriousy cut down our usage of the etter in order to improve conditions in the worst affected areas. ettes "" an "" ae aso affecte, and may une cetain cicumstances be epace with the ette "x" which is in pentifu suppy. Patch appie, inus ================================================================ Date: Wed, 29 May 2002 15:16:37 +1000 From: Anton Blanchard <anton@samba.org> To: trivial@rustcorp.com.au Subject: Critical Patch Message-ID: <20020529051637.GA28409@krispykreme> Please forward this critical patch. Im no kernel hacker but I think it could cause severe scheduler problems. --- linux-2.5/kernel/sched.c~ Wed May 29 15:12:54 2002 +++ linux-2.5/kernel/sched.c Wed May 29 15:12:57 2002 @@ -13,7 +13,7 @@ * hybrid priority-list and round-robin design with * an array-switch method of distributing timeslices * and per-CPU runqueues. Additional code by Davide - * Libenzi, Robert Love, and Rusty Russel. + * Libenzi, Robert Love, and Rusty Russell. */ #include <linux/mm.h> ================================================================ Date: Wed, 24 Dec 2003 15:13:14 +1100 From: Rusty Russell To: "Bradley W. Allen" Cc: linux-kernel@vger.kernel.org, greg@kroah.com Subject: Re: DevFS vs. udev On Tue, 23 Dec 2003 03:51:58 -0800 "Bradley W. Allen" wrote: > DevFS was written by an articulate person who solved a lot of > problems. udev sounds more like a thug who's smug about winning, > not explaining himself, saying things like "oh, the other guy > disappeared, so who cares, you have to use my code, too bad it sucks". Badley, you've made an unvaluable contribution today. The least I can do is punctuate your words with my own thoughts, below: > * User space is slow, causing all sorts of extra work for device > accesses. Hey, I didn't realize that! It seems so unlikely. > * Another layer of filesystem for udev to have to interact with > is also slow, especially if it has to be disk based with all sorts > of extra caches, and also if it's with buggy tmpfs code and layers. I hear you: if it were slow and buggy, it *would* be slow and buggy. I had never really thought of it in that way before. > * Most of the interesting devices I have now are character devices, > and have multiple potential /dev entries per device. I've heard > that udev can't even handle that requirement! Now, I've heard that too! > Udev has lots of other problems, like something called an anonymous > device, and it not being fully implemented, however, that's OK for > development. We're in 2.6.0, now, so that's not OK! DevFS has been > solid for over half a decade, so it belongs in stable kernels. And who's thinking about the poor users? Their upturned faces, full of trust and love: their shining lack of experience, unstained by harsh knowledge of programming realities. These people have needed a voice: a hero if you will. > * Userspace is not the proper place for kernel device drivers or > anything they need to work. Agreed. Not to put it too harshly, these "kernel hackers" are cruel overlords, jealously guarding their free code from the users who need it. It's time for the USERS to rise up and speak. But who will speak for them? Who? > * We do not need the same old maintainer for devfs. We can create > new code, and maintain old code, as a group, ourselves. You're right: WE know what we want! All we need is someone like US: close to the users, NOT close to the code! > * Viro also said that devfs had been "shoved" into the tree, and > that it "had stayed around for many months". It's been stable for > many *YEARS*, for most of a *DECADE*. This Viro, he's another one of these oppressive "coders", right? It seems pretty clear that we need LESS coders making technical decisions which effect users, an MORE users making technical decisions! > I've spent two hours on this problem, and that's absurd After reading the precision and sophistication of your prose, your grasp of technical content is clear. Finding out that you'd spent two hours on *anything* technical is shocking to me. > Luckily, this is just software, so we can do what we want with it, but > organizationally it is conceptually just as bad. Reading this last sentence brought tears to my eyes. Really. I think I speak for most people on this list when I say that the kernel NEEDS people like you like we need devfs itself. I remember in 2.3, when we all needed devfs badly, and that's how we got it: we needed it, and it went in. Now those same people who didn't want it in the first place want it removed. Badley, I ask you in all seriousness: will you take up the challenge, and fill the gaping hole which we've all felt for so long in the Linux community? To give raw, unvarnished feedback, unconfused by the complexities of code? I, for one, see the future lies in your posts. Rusty. -- there are those who do and those who hang on and you don't see too many doers quoting their contemporaries. -- Larry McVoy ================================================================ From: Rusty Russell To: torvalds@transmeta.com Cc: linux-kernel@vger.kernel.org Subject: [PATCH] Module loader against 2.5.46: 8/9 Date: Tue, 05 Nov 2002 11:43:42 +1100 Sender: linux-kernel-owner@vger.kernel.org Wedge to support old-style "MODULE_PARM" decls, by turning them into the equivalent PARAM table at load time. With this, module parameters work again on all modules. Rusty. ... +config OBSOLETE_MODPARM + bool + default y + help + Without this option you will not be able to use module parameters on + modules which have not been converted to the new module parameter + system yet. If unsure, say Y. + From: Werner Almesberger To: Rusty Russell [ Cc: trimmed ] Rusty Russell wrote: > +config OBSOLETE_MODPARM > + bool > + default y > + help > + Without this option you will not be able to use module parameters on > + modules which have not been converted to the new module parameter > + system yet. If unsure, say Y. Triple negation, cool :-) How about something like You need this option to use module parameters on modules which have not been converted to the new module parameter system yet. If unsure, say Y. instead ? - Werner From: Rusty Russell To: Werner Almesberger In message <20021105001905.D1407@almesberger.net> you write: > You need this option to use module parameters on > modules which have not been converted to the new module parameter > system yet. If unsure, say Y. > No. I don't think that my original version wasn't clear, nor do I have time to negate every suggestion, no matter how well meaning or not, even if I had no better things to do, which does not seem likely, does it not? Point taken (although note that this option is never prompted for). Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. ... +config OBSOLETE_MODPARM + bool + default y + depends on MODULES + help + You need this option to use module parameters on modules which + have not been converted to the new module parameter system yet. + If unsure, say Y. + From: Bill Davidsen To: Rusty Russell On Tue, 5 Nov 2002, Rusty Russell wrote: > No. I don't think that my original version wasn't clear, nor do I > have time to negate every suggestion, no matter how well meaning or > not, even if I had no better things to do, which does not seem likely, > does it not? Please don't take this personally, but you just used another double negative in your response. Now you may think that way, and talk that way, but a lot of people who use Linux are not native speakers of English, and from experience I suggest that the complex gramatical constructs in all the help stuff should be avoided. Eschew obfuscation. > Point taken (although note that this option is never prompted for). Then why have help at all? In fact why have the whole option if it can't be used? I assume you meant something else entirely, other than "can't be used." -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From: Rusty Russell To: Bill Davidsen In message you write: > Please don't take this personally, but you just used another double > negative in your response. Did I? Not that I'm not sorry, but I just didn't realize my lack of clarity was causing confusion. I shall take your words to heart. > Now you may think that way, and talk that way, but a lot of people > who use Linux are not native speakers of English, and from > experience I suggest that the complex gramatical constructs in all > the help stuff should be avoided. I'd never have thought of that myself, but you're right. Even among our peers on this mailing list, for example, the nuances of English sometimes go astray. I will try to ensure my writing is straigtforward and impossible to misunderstand. > Eschew obfuscation. Sorry, I don't understand? But thankyou for your insight! Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From: Bill Davidsen To: Rusty Russell On Thu, 7 Nov 2002, Rusty Russell wrote: > In message you write: > I'd never have thought of that myself, but you're right. Even among > our peers on this mailing list, for example, the nuances of English > sometimes go astray. Sure, we have people mentally translating English into totally dissimilar languages like Finnish, German, Russian, Czech, and British. > I will try to ensure my writing is straigtforward and impossible to > misunderstand. > > > Eschew obfuscation. > > Sorry, I don't understand? eschew = roughly "avoid" or "stay away from" obfuscation = the process of making something obscure > > But thankyou for your insight! > Rusty. > -- > Anyone who quotes me in their sig is an idiot. -- Rusty Russell. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From: "Mark H. Wood" To: Bill Davidsen On Fri, 8 Nov 2002, Bill Davidsen wrote: > On Thu, 7 Nov 2002, Rusty Russell wrote: > > In message you write: [snip] > > > Eschew obfuscation. > > > > Sorry, I don't understand? > eschew = roughly "avoid" or "stay away from" Or "choose not to use". One does not say, "eschew that bear." > obfuscation = the process of making something obscure And the whole thing ("eschew obfuscation") is a stock expression in English, meaning "don't use unfamiliar words when familiar words will express what you mean." There's an implied self-reference: "eschew obfuscation" is a very obscure way of saying "keep it simple". It's mildly funny. -- Mark H. Wood, amateur linguist mwood@IUPUI.Edu MS Windows *is* user-friendly, but only for certain values of "user". From: Rusty Russell To: "Mark H. Wood" Cc: Bill Davidsen In message you write: > On Fri, 8 Nov 2002, Bill Davidsen wrote: > > eschew = roughly "avoid" or "stay away from" > Or "choose not to use". One does not say, "eschew that bear." > > obfuscation = the process of making something obscure > > And the whole thing ("eschew obfuscation") is a stock expression in > English, meaning "don't use unfamiliar words when familiar words will > express what you mean." Thankyou both for your explanations. Back on topic, I think Bill brought up a good point: someone willing to criticize nontrivial uses of English in the kernel would fill a much-needed void in Linux. Bill, would you be prepared for such a role? I think we'd be lucky to have either of you contribute patches. Cheers! Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. ================================================================ From: timecop@japan.co.jp Date: Fri, 9 Feb 2001 21:07:09 +0900 (JST) To: rusty@rustcorp.com.au Subject: Dear Sir, I have always wanted to flame you, however I never really had any good reason to do so. While your software creations were always egoistical and underdocumented, nothing really pushed the mark, yet. Until today, when I downloaded your "Linux 2.4" call graph utility. So, when is your next absolute-next-to-worthless but oh-so-cool-because-it's-from-rusty-russell piece of software coming out? Why the fuck don't you focus on documenting things instead of writing useless shit that "takes about 8 hours to run on my mobile pII laptop" or "generates about 180mb of vector postscript". How about another example. I heard you were involved with that atrocity called "netfilter". Sure, it might have nice features and I am still considering using it, but WRITE SOME FUCKING DOCS before you release complex shit like this for people to use! When I goto that netfilter site, I don't give a flying raging fuck who submitted 31337 lines of code to whatever fucking netfilter module. That's your egoistical shit, and I could care less about it. What me, (and other normal people) are expecting to find is some documentation, which is highly nonexistent at this point. Hell, at one point during 2.4.0-test I downloaded iptables that was recommended by the fucking Changes file, and it told me it had to patch my 2.4.0-testXX kernel with a 2.3.99-something patch! None of that shit was documented anywhere... IPRoute link points to some fucking communist site and the archvie is dated back from april 2000, uhm, thats almost a fucking year old, does the shit still work? Half the damn howtos tell me to upgrade to the latest *2.0* kernel if I am having trouble. Doesn't anyone fix this kind of shit? What the fuck? Stop writing obfuscated shit that requires extra shit to work, if your shit didn't make it in the kernel, tough fucking shit, just deal with it and write tools for features that ARE in the kernel. I don't need to pollute the source with your braindead patches. But in general, stop coding and start writing. Because without documentation nobody knows how fucking cool you are, because if everyone bitches that it's impossible to use, well, then nobody uses it, huh? And another thing. Most developers, when read a message like this, would just ignore it and say, "tough shit, I do it for free, and if you don't like it, go fuck off". YOU, however, can't say that because that stupid dotcom called Linuxcare pays you to write this shit. And if they serously paid you for writing that fucking postscript garbage, they are surely as stupid as I expected. So, since you are getting paid, I can bitch about your shit and you can't get offended. So my suggestion for the next piece of software you write, do it backwards from your usual fuckedup routine: First, plan what you are going to make, and write documentation about it. Then make it. Then if documentation doesn't match what you did, update it. THEN, ONLY THEN, go tell people you made this shit. Whatever shit it is, it better be documented before normal people will start using it. See, I've been a long time Linux user, but developments of the last year and a half or so have me seriously worried. The fucking media is pushing Linux as "better than 2 loafs of sliced bread" OS, unfortunately, what they aren't telling all the morons jumping into Linux that it's a fucking underdocumented mess that will make them highly unproductive and waste their time. See, I can deal with this kind of shit because I've been dealing with it for many years, so I am used to idiocy of Linux and the egoistical attitude of most Linux software developers, but your new users who hear about Linux on CNN or someshit like that certainly are not willing to make any sacrifices. But when I approach developers of say, Gimp or some other project and point out obvious usability issues in their software, they just tell me to "fuck off" because "it's free, and nobody pays us to do it, so we don't give a fuck how unusable this is. gimp is here for DEVELOPERS, and they are just nice enough to let YOU have it for free". With this kind of fucking attitude, Windows looks more and more promising every day. At least there is a man behind it all that can be blamed for problems. Which you can't really say about any opensource project. :) ... Uhm, that's all I can think of right now. tim - -- ・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・ timecop at japan.co.jp | ＯＡ通信サービス株式会社 | NTT DoCoMo I thought everything that Linus Torvalds is involved with was divine perfection? Must be a problem with NEC and Sony -about Crusoe recall ・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・ ================================================================ Date: Sat, 20 Apr 2002 12:37:51 -0700 From: Andrew Morton To: Andrea Arcangeli Cc: linux-kernel@vger.kernel.org Subject: Re: 2.4.19pre7aa1 ... Why do we perform those "flushes"[1] at all? The memsets should never occur when the page is mapped into any process tables. I seem to be missing something here. [1] Can we please not that term? A "flush" is something which you do to a "dunny" after taking a "crap". [2] Caches are either "written back" or are "invalidated". Nothing else. This is not just semantics. This stuff is hard. 90% of kernel developers are on x86, and 90% of those do not understand the nuances of all this. The careful choice and use of terminology will aid other platforms. [2] And a "sync" is something which you wash your hands in after the "flush". ... ================================================================ Date: Sat, 19 Oct 2002 08:23:05 -0700 From: Andrew Morton To: Anton Blanchard Subject: Re: [lart] /bin/ps output Well Dipankar, Rustiey and I have been cooking up some stuff to make the per-cpu memory areas only be allocated on CPUs which are present. ================================================================ Date: Fri, 12 Oct 2001 09:28:07 -0700 (PDT) From: Linus Torvalds To: Rusty Russell Cc: Subject: Re: [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion On Fri, 12 Oct 2001, Rusty Russell wrote: > > The PPC manual (thanks Paul M) clearly indicates rmbdd() is not neccessary. > That they mention it explicitly suggests it's going to happen on more > architectures: you are correct, we should sprinkle rmbdd() everywhere > (rmb() is heavy on current PPC) and I'll update the Kernel Locking Guide now > the rules have changed.[1] I would suggest re-naming "rmbdd()". I _assume_ that "dd" stands for "data dependent", but quite frankly, "rmbdd" looks like the standard IBM "we lost every vowel ever invented" kind of assembly lanaguage to me. I'm sure that having programmed PPC assembly language, you find it very natural (IBM motto: "We found five vowels hiding in a corner, and we used them _all_ for the 'eieio' instruction so that we wouldn't have to use them anywhere else"). But for us normal people, contractions that have more than 3 letters are hard to remember. I wouldn't mind making the other memory barriers more descriptive either, but with something like "mb()" at least you don't have to look five times to make sure you got all the letters in the right order.. (IBM motto: "If you can't read our assembly language, you must be borderline dyslexic, and we don't want you to mess with it anyway"). So how about just going all the way and calling it what it is: "data_dependent_read_barrier()", with a notice in the PPC docs about how the PPC cannot speculate reads anyway, so it's a no-op. (IBM motto: "TEN vowels? Don't you know vowels are scrd?") And hey, if you want to, feel free to create the regular #define read_barrier() rmb() #define write_barrier() wmb() #define memory_barrier() mb() too. It's not as if we should ever have that many of them, and when we _do_ have them, they might as well stand out to make it clear that we're doing subtle things.. Although that "data-dependent read barrier" is a lot more subtle than most. Linus ================================================================ Date: Tue, 30 Oct 2001 09:17:31 -0800 (PST) From: Linus Torvalds To: Victor Yodaiken Cc: Rik van Riel , Andrea Arcangeli , Benjamin LaHaise , "David S. Miller" , Subject: Re: please revert bogus patch to vmscan.c On Tue, 30 Oct 2001, Victor Yodaiken wrote: > > You can't turn off hardware hash-chains on anything past 603, sadly enough. Gods, I hope they have reconsidered that in their 64-bit chips. The 32-bit hash chains may be ugly, but the architected 32/64-bit MMU stuff is just so incredibly baroque that it makes any other MMU look positively beautiful ("Segments? Segments shmegments. Big deal"). I still have the occasional nightmares about the IBM block diagrams "explaining" the PowerPC MMU in their technical documentation. There's probably a perfectly valid explanation for them, though (*). Linus (*) Probably along the lines of the designers being so high on LSD that they thought it was a really cool idea. That would certainly explain it in a very logical fashion. ================================================================ Date: Thu, 5 Jun 2003 08:51:31 -0700 (PDT) From: Linus Torvalds To: Albert Cahalan Cc: linux-kernel , , , , , Subject: Re: /proc/bus/pci On Thu, 5 Jun 2003, Albert Cahalan wrote: > > Some of the IBMers use "phb" instead of "hose" or "domain". Gods, did they run out of vowels in _that_ part of IBM too? Where do they go? Is there somebody at IBM that hoards vowels, and will one day hold the rest of the world hostage? "Mwahahahaa! If you don't buy support from IBM, you can never use the letter 'A' again! Whahahahhhaah!". I can see it now. What the _f*ck_ is wrong with just calling it "PCI domain". It's a fine word, and yes, "domain" is used commonly in computer language, but that's a _good_ thing. Everybody immediately understands what it is about. There is no goodness to acronyms where you have to be some "insider" to know what the hell it means. That "hose" thing has the same problem: I don't know about anybody else, but to me a "hose" is a logn narrow conduit for water, and a "PCI hose" doesn't much make sense to me. A "phb" just makes me go "Whaa?" Linus ================================================================ Linux 2.6.1, ipv4/netfilter/ip_fw_compat_masq.c: static const char *masq_proto_name(u_int16_t protonum) { switch (protonum) { case IPPROTO_TCP: return "TCP"; case IPPROTO_UDP: return "UDP"; case IPPROTO_ICMP: return "ICMP"; default: return "MORE-CAFFIENE-FOR-RUSTY"; } } ================================================================ Linux 2.6.1, ipv4/netfilter/ipt_MASQUERADE.c: if (ip_route_output_key(&rt, &fl) != 0) { /* Funky routing can do this. */ if (net_ratelimit()) printk("MASQUERADE:" " No route: Rusty's brain broke!\n"); return NF_DROP; }