* The well-factored 386 @ 2003-07-28 16:02 Jack Dennon 2003-07-28 16:32 ` David S. Miller 0 siblings, 1 reply; 32+ messages in thread From: Jack Dennon @ 2003-07-28 16:02 UTC (permalink / raw) To: linux-kernel hmm...didn't seem off-topic to me. Anything about 386 hardware would seem to be rather closely related to Linux assembly language programming. jdennon@seasurf.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386 2003-07-28 16:02 The well-factored 386 Jack Dennon @ 2003-07-28 16:32 ` David S. Miller 2003-07-28 16:46 ` Andries Brouwer 2003-07-28 19:41 ` Jamie Lokier 0 siblings, 2 replies; 32+ messages in thread From: David S. Miller @ 2003-07-28 16:32 UTC (permalink / raw) To: Jack Dennon; +Cc: linux-kernel On Mon, 28 Jul 2003 09:02:32 -0700 Jack Dennon <jdd@seasurf.net> wrote: > hmm...didn't seem off-topic to me. > Anything about 386 hardware would seem > to be rather closely related to Linux > assembly language programming. He talks about his x86 emulator he wrote, and people complain to me all the time about his postings. Nobody ever follows up to any of his postings, he's not even discussing anything, he's just showing how great he thinkgs his x86 emulator is. linux-kernel is not a bullhorn for people like him to use... ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386 2003-07-28 16:32 ` David S. Miller @ 2003-07-28 16:46 ` Andries Brouwer 2003-07-28 16:55 ` David S. Miller 2003-07-28 19:41 ` Jamie Lokier 1 sibling, 1 reply; 32+ messages in thread From: Andries Brouwer @ 2003-07-28 16:46 UTC (permalink / raw) To: David S. Miller; +Cc: Jack Dennon, linux-kernel On Mon, Jul 28, 2003 at 09:32:45AM -0700, David S. Miller wrote: > > hmm...didn't seem off-topic to me. > > Anything about 386 hardware would seem > > to be rather closely related to Linux > > assembly language programming. > > He talks about his x86 emulator he wrote, and people complain to me > all the time about his postings. > > Nobody ever follows up to any of his postings, he's not even > discussing anything, he's just showing how great he thinkgs > his x86 emulator is. > > linux-kernel is not a bullhorn for people like him to use... Rick A Hohensee is a clown, a joker, a troll. One can be amused by his postings, or irritated, or one can ignore them. No need for any formal action. You on the other hand threaten with censorship. That is not funny at all. Censorship would explode in a terrible flamewar. There is no need for such censorship. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386 2003-07-28 16:46 ` Andries Brouwer @ 2003-07-28 16:55 ` David S. Miller 2003-07-28 19:31 ` Herbert Pötzl 0 siblings, 1 reply; 32+ messages in thread From: David S. Miller @ 2003-07-28 16:55 UTC (permalink / raw) To: Andries Brouwer; +Cc: jdd, linux-kernel On Mon, 28 Jul 2003 18:46:21 +0200 Andries Brouwer <aebr@win.tue.nl> wrote: > You on the other hand threaten with censorship. > That is not funny at all. Run your own mailing lists, then you can tell people what is appropriate or not appropriate for list discussions and then decide how to deal with people who ignore such requests to stay on-topic. Do you accuse me of censoring spammers too? I filter them too. :-) Off topic postings take people's time, and we have enough traffic with just the on-topic stuff as it is. If you find pleasure in having to figure out what the regexps are each day needed in order to filter out all the GPL, OSDL, bitkeeper, whatever threads on linux-kernel each and every day on this list that's ok, but most other people do not find this a fun activity at all. The fact is that people like to abuse linux-kernel because of how large an audience they know it reaches. And frankly, I'm simply not going to tolerate people being jackasses and using linux-kernel as a bullhorn to discuss whatever they think every needs to hear about. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386 2003-07-28 16:55 ` David S. Miller @ 2003-07-28 19:31 ` Herbert Pötzl 0 siblings, 0 replies; 32+ messages in thread From: Herbert Pötzl @ 2003-07-28 19:31 UTC (permalink / raw) To: David S. Miller; +Cc: linux-kernel On Mon, Jul 28, 2003 at 09:55:06AM -0700, David S. Miller wrote: > On Mon, 28 Jul 2003 18:46:21 +0200 > Andries Brouwer <aebr@win.tue.nl> wrote: > > > You on the other hand threaten with censorship. > > That is not funny at all. > > Run your own mailing lists, then you can tell people > what is appropriate or not appropriate for list discussions > and then decide how to deal with people who ignore such > requests to stay on-topic. > > Do you accuse me of censoring spammers too? I filter > them too. :-) maybe you could add the subscribe/unsubscribe messages (sent to lkml, not majordomo ;) to your filters ... 8-) best, Herbert ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386 2003-07-28 16:32 ` David S. Miller 2003-07-28 16:46 ` Andries Brouwer @ 2003-07-28 19:41 ` Jamie Lokier 2003-07-29 11:14 ` Helge Hafting 1 sibling, 1 reply; 32+ messages in thread From: Jamie Lokier @ 2003-07-28 19:41 UTC (permalink / raw) To: David S. Miller; +Cc: Jack Dennon, linux-kernel David S. Miller wrote: > He talks about his x86 emulator he wrote, and people complain to me > all the time about his postings. > > Nobody ever follows up to any of his postings, he's not even > discussing anything, he's just showing how great he thinkgs > his x86 emulator is. I didn't realise he was talking about an x86 emulator. I thought he was analyzing real hardware. The one thing that made it on-topic for me was his quiet suggestion that "forreal" mode interrupts are faster, and that it might, perhaps, be possible to modify a Linux kernel to run in that mode - to take advantage of the faster interrupts. -- Jamie ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386 2003-07-28 19:41 ` Jamie Lokier @ 2003-07-29 11:14 ` Helge Hafting 2003-07-29 16:19 ` Jamie Lokier 0 siblings, 1 reply; 32+ messages in thread From: Helge Hafting @ 2003-07-29 11:14 UTC (permalink / raw) To: Jamie Lokier; +Cc: linux-kernel On Mon, Jul 28, 2003 at 08:41:27PM +0100, Jamie Lokier wrote: > I didn't realise he was talking about an x86 emulator. I thought he > was analyzing real hardware. > > The one thing that made it on-topic for me was his quiet suggestion > that "forreal" mode interrupts are faster, and that it might, perhaps, > be possible to modify a Linux kernel to run in that mode - to take > advantage of the faster interrupts. That would have to be a kernel for very special use. The "forreal" mode has protection turned off. As far as I know, that means any user process can take over the cpu as if it was running in kernel mode. Perhaps useful for some embedded use with only a couple well-tested processes running. Still, a programming error could overwrite kernel memory instead of segfaulting. Helge Hafting ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386 2003-07-29 11:14 ` Helge Hafting @ 2003-07-29 16:19 ` Jamie Lokier 2003-07-30 7:11 ` Helge Hafting 0 siblings, 1 reply; 32+ messages in thread From: Jamie Lokier @ 2003-07-29 16:19 UTC (permalink / raw) To: Helge Hafting; +Cc: linux-kernel Helge Hafting wrote: > > The one thing that made it on-topic for me was his quiet suggestion > > that "forreal" mode interrupts are faster, and that it might, perhaps, > > be possible to modify a Linux kernel to run in that mode - to take > > advantage of the faster interrupts. > > That would have to be a kernel for very special use. The "forreal" > mode has protection turned off. As far as I know, that > means any user process can take over the cpu as if > it was running in kernel mode. There are quite a few embedded systems where that is ok, especially if performance is improved. Also, I am not sure whether paging still works in "forreal" mode. If it does, kernel memory could still be protected. Not well enough for security, but enough to protect against programming errors. -- Jamie ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386 2003-07-29 16:19 ` Jamie Lokier @ 2003-07-30 7:11 ` Helge Hafting 2003-07-30 14:05 ` Jamie Lokier 0 siblings, 1 reply; 32+ messages in thread From: Helge Hafting @ 2003-07-30 7:11 UTC (permalink / raw) To: Jamie Lokier; +Cc: linux-kernel On Tue, Jul 29, 2003 at 05:19:51PM +0100, Jamie Lokier wrote: > Helge Hafting wrote: > > > The one thing that made it on-topic for me was his quiet suggestion > > > that "forreal" mode interrupts are faster, and that it might, perhaps, > > > be possible to modify a Linux kernel to run in that mode - to take > > > advantage of the faster interrupts. > > > > That would have to be a kernel for very special use. The "forreal" > > mode has protection turned off. As far as I know, that > > means any user process can take over the cpu as if > > it was running in kernel mode. > > There are quite a few embedded systems where that is ok, especially if > performance is improved. > > Also, I am not sure whether paging still works in "forreal" mode. If > it does, kernel memory could still be protected. Not well enough for > security, but enough to protect against programming errors. > Paging works even in real mode, afaik. 386es used to emulate "expanded" memory (a simple bank-switching thing for 286) by going into protected mode, change the page tables, then return to real mode with paging still enabled. So you can probably use paging in "forreal" mode too. I believe you only get the page table's memory mapping capabilities though, I don't think you get protection of "kernel" pages without protection enabled. You could still "hide" kernel memory by giving userspace another page table, but that means page table switching on each syscall which kills performance worse than interrupt handling in protecxted mode. Helge Hafting ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386 2003-07-30 7:11 ` Helge Hafting @ 2003-07-30 14:05 ` Jamie Lokier 0 siblings, 0 replies; 32+ messages in thread From: Jamie Lokier @ 2003-07-30 14:05 UTC (permalink / raw) To: Helge Hafting; +Cc: linux-kernel Helge Hafting wrote: > So you can probably use paging in "forreal" mode too. I believe > you only get the page table's memory mapping capabilities > though, I don't think you get protection of "kernel" pages > without protection enabled. > > You could still "hide" kernel memory by giving userspace another > page table, but that means page table switching on each > syscall which kills performance worse than interrupt handling > in protecxted mode. Yes, that's exactly what I had in mind. You say that page table switching kills performance, but consider Ingo's latest 64G patches do exactly that, and performance, though degraded, is not too bad. Whether it's worth doing that would depend on the balance of interrupts vs. syscalls. Some embedded applications are dominated by interrupts, and there are apps which avoid syscalls altogether during the main part of their running. -- Jamie ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386
@ 2003-07-29 12:59 John Bradford
2003-07-29 13:32 ` Ville Herva
0 siblings, 1 reply; 32+ messages in thread
From: John Bradford @ 2003-07-29 12:59 UTC (permalink / raw)
To: helgehaf, jamie; +Cc: linux-kernel
> > I didn't realise he was talking about an x86 emulator. I thought he
> > was analyzing real hardware.
> >
> > The one thing that made it on-topic for me was his quiet suggestion
> > that "forreal" mode interrupts are faster, and that it might, perhaps,
> > be possible to modify a Linux kernel to run in that mode - to take
> > advantage of the faster interrupts.
>
> That would have to be a kernel for very special use. The "forreal"
> mode has protection turned off. As far as I know, that
> means any user process can take over the cpu as if
> it was running in kernel mode.
>
> Perhaps useful for some embedded use with only a couple well-tested
> processes running. Still, a programming error could overwrite
> kernel memory instead of segfaulting.
Anything that's single user and non-networked isn't beyond the realms
of feasability - it would be useful for a games console, or high
performance graphics work.
It would be an interesting project, but what concerns me is how well
implemented these non-standard modes actually are. It's possible that
there are processors out there that don't work reliably with them, or
don't implement them at all.
John.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The well-factored 386 2003-07-29 12:59 John Bradford @ 2003-07-29 13:32 ` Ville Herva 0 siblings, 0 replies; 32+ messages in thread From: Ville Herva @ 2003-07-29 13:32 UTC (permalink / raw) To: John Bradford; +Cc: helgehaf, jamie, linux-kernel, tosh On Tue, Jul 29, 2003 at 01:59:41PM +0100, you [John Bradford] wrote: > > > I didn't realise he was talking about an x86 emulator. I thought he > > > was analyzing real hardware. > > > > > > The one thing that made it on-topic for me was his quiet suggestion > > > that "forreal" mode interrupts are faster, and that it might, perhaps, > > > be possible to modify a Linux kernel to run in that mode - to take > > > advantage of the faster interrupts. > > > > That would have to be a kernel for very special use. The "forreal" > > mode has protection turned off. As far as I know, that > > means any user process can take over the cpu as if > > it was running in kernel mode. > > > > Perhaps useful for some embedded use with only a couple well-tested > > processes running. Still, a programming error could overwrite > > kernel memory instead of segfaulting. > > Anything that's single user and non-networked isn't beyond the realms > of feasability - it would be useful for a games console, or high > performance graphics work. > > It would be an interesting project, but what concerns me is how well > implemented these non-standard modes actually are. It's possible that > there are processors out there that don't work reliably with them, or > don't implement them at all. Have you looked at Kernel Mode Linux? http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/ I don't think it uses "forreal" mode, but it allows running selected user processes in kernel mode thus getting rid of system call overhead. [Note to Toshiyuki Maeda: the complete thread is at http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&threadm=expl.8vH.27%40gated-at.bofh.it&rnum=1&prev=/groups%3Fq%3DThe%2Bwell-factored%2B386%26num%3D50%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26sa%3DN%26tab%3Dwg in case you want to catch some context. The "forreal" idea is mentioned in the first mail of the thread.] -- v -- v@iki.fi ^ permalink raw reply [flat|nested] 32+ messages in thread
* The Well-Factored 386 @ 2003-07-28 8:44 Rick A. Hohensee 2003-07-28 14:06 ` David S. Miller 0 siblings, 1 reply; 32+ messages in thread From: Rick A. Hohensee @ 2003-07-28 8:44 UTC (permalink / raw) To: linux-kernel, linux-assembly The four actual main modes of the 386 Operation of the INTeL 80386 is clearly much more flexible than currently used, as far as the basic states the machine can run in. "Real Mode" and "Protected Mode" are two possibilities out of several that are concievably useful. It can be seen from things that are possible in "Real Mode", such as "Unreal Mode", use of 386-era instructions and so on, that the canonical modes are not monolithic entities, but are cases of various combinations of discrete state switches. There is no 8086 in a 386. Canonical Wake-up Real Mode, which I will refer to as CWR Mode, seems to be how these several state switches are set at machine reset, but are semantically just settings of independant things, and clearly CWR Mode can be set up from individual settings available to the user. This is also much more evident from a careful traversal of the detailed instruction specs in the INTeL Programmer's Reference (386INTEL.TXT) for the 80386. I'd say the two most global switches in the machine are the PE bit, Protection Enabled, quite sensibly placed at bit 0 in control register 0, and the D bit of the active code segment descriptor affiliated with CS, the Default Bit. Two bits gives four possible states. All four are capable of being the default mode of a system. Two are used as such; CWR Mode and Protected Mode. Here's a breakdown and some neologizing... PE=0 Dbit=0 (un)Real Mode PE=0 Dbit=1 Forreal Mode PE=1 Dbit=0 Veal Mode (BKA "286 task") PE=1 Dbit=1 Protected Mode The documented modes are the outside cases in a binary-count listing, where PE=Dbit. There's a very good reason for that. IRET is sensitive to Dbit, whereas interrupts push a stack frame of operands sized in accordance with PE. This is some of INTeL's* description of the action of INT, which represents all interrupts in this regard, when PE=0... IF PE = 0 THEN GOTO REAL-ADDRESS-MODE; REAL-ADDRESS-MODE: Push (FLAGS); IF <! 0; (* Clear interrupt flag *) TF <! 0; (* Clear trap flag *) Push(CS); Push(IP); (* No error codes are pushed *) CS <! IDT[Interrupt number * 4].selector; IP <! IDT[Interrupt number * 4].offset; That is, IP is pushed if PE=0, not EIP. FLAGS is also a dual (a "word" in INTeLese, 16 bits). Thus if, for example, you are in Forreal Mode, you get a 6-byte stack push of FLAGS, CS and then IP on an interrupt, and the corresponding IRET will later pop 12 bytes for basically the same 3 registers, and the system streaks off to the big bitbucket in the sky. HOW ever, IRET is only PARTIALLY sensitive to Dbit. What I didn't say a moment ago is that IRET is really sensitive to the current effective code size, of which the D bit is just one component. If we prefix the IRET in a Forreal Mode interrupt handler with 0x66, the other-operand-size prefix, it will pop duals in a use32 CS. The interrupt occuring with PE=0 pushed duals. It works. The inside cases of Veal Mode and Forreal Mode simply need thier IRETs un-default-sized. In Veal Mode you coerce IRET into using quads in a use16 code segment, and in Forreal Mode the same prefix in a use32 code segment will coerce the IRET pops to duals. In Veal Mode, where PE=1 when an interrupt occurs, you also have the option of handling the interrupt with a Dbit=1 segment for the pertinent interrupt handler, in which case it can IRET back to Veal Mode with a naked IRET. I suppose you can also segregate Veal Mode segments with thier descriptor bases and limits. In all the quirkiness of the 386, the broad orthogonality of the other-sizing prefixes is quite refreshing, and even works on stuff like POPA. This is from the blow-by-blow description of IRET... IF OperandSize = 32 (* Instruction = IRETD *) THEN EIP <! Pop(); ELSE (* Instruction = IRET *) IP <! Pop(); Again, OperandSize is Dbit as effected by a possible prefix. This is why INTeL only mentions Veal Mode as "286 tasks". Tasks don't IRET. Most of what a 386 provides big facilities for, like tasks, can also be done piecemeal, as would be the case running a system in straight Forreal Mode. Canonical Wake-up Real Mode and Unreal Mode are two flavors of the same basic setting of PE and Dbit. The difference is in segment limits. This points up a basic concept here. 8086-style segments are a lightweight layer that may or may not be active, but 386 segments are always active. PE=0 does not turn them off. PE=0 means you can't change them until you turn PE back to 1. PE should be called "PCE, Protections Changes Enabled". This means the four basic modes have a state diagram about like so... _______________ | WAKE-UP | |canonical rmode| | PE=0 use16 | |_______________| A |set PE to 1 | | set PE to 0| | ___|________V__ | Veal | | Mode | | PE=1 use16 | |_______________| A |far xfer | | to use32 CS far xfer to | | use16 CS| | ___|_______V___ | Protected | | Mode | | PE=1 use32 | |_______________| A |set PE to 1 | | set PE to 0| | ___|________V__ | Forreal Mode | | Mode | | PE=0 use32 | |_______________| Interesting. Forreal Mode is the furthest from Wake-up, and you can only get to Forreal Mode from pmode. Forreal Mode is like a back room off of pmode. You can interrupt between pmode and Veal Mode. Conversely, events in rmode or Forreal Mode (PE=0) have to be handled in the mode they occur in. The above diagram does not account for different segment limits and bases than those in effect in WakeUp Rmode, so e.g. unreal mode is not shown. This chart also does not account for V86 Mode, which basically requires 386 task-switch constructs. The above modes and transitions do NOT need a TSS, or paging. I suspect V86 could run off Veal Mode OR pmode. Veal Mode is a protected mode. That means it's a quick switch to good old use32 Protected Mode. It may afford some better code density, and thus speed. Forreal Mode is unprotected, which means interrupts are handled somewhat faster, which benefits realtime services. Either can be incorporated into a multi-mode system. Forreal Mode also doesn't seem to have any analogy at all in current use, other than the INTeL "flat model", which is a simplified pmode, but that similarity is rather superficial. For the 386 to do what it does, and particularly to have pulled it off in the mid-eighties, things have to be fairly simple. You can figure that whatever the 386 does, it's implemented as simply as possible. The modes of the machine are composites of simple switches, and various effects, such as loaded descriptors, tend to persist until changed. This has always been the case with e.g. 8086 segment registers. In the 386, however, 8086-style "segments" are not alternates of 386 segments, they are a superficiality on top of them. With that in mind, the states one goes through simply getting from real mode to pmode start to make more sense. The following (osimplay) code demonstrates the superficiality of 8086 "schmegments" vis-a-vis 386 segments, even when PE=0... <from flat pmode> . global/flipPE # Welcome to Forreal Mode # cell still 4 = 4 to A # 32-bit schmegmented addressing demo = A to ES # proving we got PE = to 0. = 9348539 to A = A to @ $((0xb8a00)) ES = A to @ $((0xb8a00)) That code causes two identical attribute-glyph pairs to appear on the VGA text screen 32 charcells displaced from each other. That is the 4 in ES, times 16 as per 8086, divided by two since each charcell is 2 bytes. Plus a flat 32-bit address to put it on the screen. Forreal Mode thus does 32-bit 8086 schmegmented address computation. What is this type of addressing useful for? Precious little. In Forreal mode you've got 32 bits to start with. The point is you have the big flat segments left over from pmode. The 8086 address-math does prove we're not in pmode any more, however. Otherwise the ES prefix of 4 would have GPFed. Rick Hohensee Precision Mojo Engineer * I've converted my 386INTEL.TXT to 7-bit ASCII-art, not to mention op-source-dest and other unINTeLifications, and "<!" is the right-to-left assignment operator in the instruction description code, helpfully pronounced "becomes". The appended hex/octal/listing appears to be handling INT 35 in Forreal Mode, ala otheroperandsize dismiss It also demos the 32-bit schmegmented addressing mentioned earlier, and it keeps it's IDT in the VGA text buffer. The hex/octal input editor in osimplay needed to type it in is Left As An Excercize To The Reader. 00000000 00... ALLOT 0x7C00 00007c00 270 28 02 = 552 to A 00007c03 271 01 00 = 1 to C 00007c06 31 322 XOR D with D 00007c08 8e 302 = D to ES 00007c0a 273 00 7c = 0x7c00 to B 00007c0d cd 13 submit 0x13 00007c0f fa nosurprises 00007c10 270 00 b8 = 0xb800 to A 00007c13 8e 330 = A to DS 00007c15 270 93 0d = 3475 to A 00007c18 89 006 2c 01 = A to @ 300 00007c1c 31 300 XOR A with A 00007c1e 8e 330 = A to DS 00007c20 0f 01 16 37 7d setGDT IGDTRpointer 00007c25 270 00 b8 = 0xb800 to A 00007c28 8e 330 = A to DS 00007c2a 270 94 0d = 3476 to A 00007c2d 89 006 30 01 = A to @ 304 00007c31 66 otheroperandsize 00007c32 31 300 XOR A with A 00007c34 100 1+ A 00007c35 0f 22 300 = A to CR0 00007c38 e9 00 00 jump hvfnvkfv 00007c3b (O) hvfnvkfv 00007c3b 89 006 34 01 = A to @ 308 00007c3f 89 006 35 01 = A to @ 309 00007c43 0f 20 300 = CR0 to A 00007c46 89 006 36 01 = A to @ 310 00007c4a 89 006 37 01 = A to @ 311 00007c4e ea 53 7c 10 00 00007c53 (O) u32 00007c53 270 18 00 00 00 = 0x18 to A 00007c58 8e 330 = A to DS 00007c5a 270 57 65 67 13 = 325543255 to A 00007c5f 89 005 d4 00 00 00 = A to @ 212 00007c65 89 005 d8 80 0b 00 = A to @ 753880 00007c6b 89 005 78 81 0b 00 = A to @ 754040 00007c71 89 005 18 82 0b 00 = A to @ 754200 00007c77 270 18 00 00 00 = 0x18 to A 00007c7c 8e 330 = A to DS 00007c7e 8e 300 = A to ES 00007c80 8e 320 = A to SS 00007c82 31 300 XOR A with A 00007c84 8e 340 = A to FS 00007c86 8e 350 = A to GS 00007c88 270 d1 00 00 00 = 0xd1 to A 00007c8d 272 64 00 00 00 = 0x64 to D 00007c92 ee send byte 00007c93 90 nop 00007c94 90 nop 00007c95 90 nop 00007c96 90 nop 00007c97 90 nop 00007c98 90 nop 00007c99 90 nop 00007c9a 90 nop 00007c9b 90 nop 00007c9c 90 nop 00007c9d 270 df 00 00 00 = 0xdf to A 00007ca2 272 60 00 00 00 = 0x60 to D 00007ca7 ee send byte 00007ca8 272 92 00 00 00 = 0x92 to D 00007cad ec recieve byte 00007cae 0d 02 00 00 00 OR 2 to A 00007cb3 ee send byte 00007cb4 (O) a20loop 00007cb4 270 55 55 aa aa = 0xaaaa5555 to A 00007cb9 89 005 d8 ff 1f 00 = A to @ 2097112 00007cbf 8b 035 d8 ff 1f 00 = @ 2097112 to B 00007cc5 39 303 -test A to B 00007cc7 0f 85 e7 ff ff ff when not zero a20loop 00007ccd 274 f0 ef 00 00 = 61424 to SP 00007cd2 31 377 XOR DI with DI 00007cd4 (O) perFMIDTvector 00007cd4 60 pushcore 00007cd5 270 aa 7d 00 00 = twitch32unP to A 00007cda e8 ae 00 00 00 call install32unP 00007cdf 61 pullcore 00007ce0 107 1+ DI 00007ce1 81 377 ff 00 00 00 -test 255 with DI 00007ce7 75 eb when not zero short perFMIDTvector 00007ce9 0f 01 1d bb 7d 00 00 setIDT IDT32unPpointer 00007cf0 31 333 XOR B with B 00007cf2 103 1+ B 00007cf3 0f 20 300 = CR0 to A 00007cf6 31 330 XOR B to A 00007cf8 0f 22 300 = A to CR0 00007cfb 270 04 00 00 00 = 4 to A 00007d00 8e 300 = A to ES 00007d02 270 bb a5 8e 00 = 9348539 to A 00007d07 89 005 00 8a 0b 00 = A to @ 756224 00007d0d 26 ES 00007d0e 89 005 00 8a 0b 00 = A to @ 756224 00007d14 66 otheroperandsize 00007d15 9c pushflags 00007d16 66 otheroperandsize 00007d17 68 00 00 push 0 00007d1a 66 otheroperandsize 00007d1b e8 8c 00 call twitch32unP 00007d1e (O) theloop 00007d1e 8b 005 88 88 0b 00 = @ 755848 to A 00007d24 100 1+ A 00007d25 89 005 88 88 0b 00 = A to @ 755848 00007d2b cd 23 submit 35 00007d2d 90 nop 00007d2e 90 nop 00007d2f 90 nop 00007d30 90 nop 00007d31 e9 e8 ff ff ff jump theloop 00007d36 f4 halt 00007d37 (O) IGDTRpointer 00007d37 00 04 3d 7d 00 00 00007d3d (O) GDT 00007d3d 00 00 00 00 00 00 00 00 0 the required NULL 00007d45 ff ff 00 00 00 89 cf 00 1 0x8 TSS stackstack 00007d4d ff ff 00 00 00 9a cf 00 2 0x10 ring0 USE32 CS 00007d55 ff ff 00 00 00 92 cf 00 3 0x18 ring0 data 00007d5d ff ff 00 00 00 9a 00 00 4 0x20 USE16 CS 00007d65 ff ff 00 00 00 92 00 00 5 0x28 USE16 data ?S 00007d6d 00 00 00 00 00 00 00 00 6 0x30 00007d75 00 00 00 00 00 00 00 00 7 0x38 00007d7d 00 00 00 00 00 00 00 00 8 0x40 00007d85 00 00 00 00 00 00 00 00 9 0x48 00007d8d 00007d8d (O) install32unP 00007d8d c1 347 02 upshift 2 to DI 00007d90 81 307 00 80 0b 00 + IDT32unP to DI 00007d96 89 007 = A to @ DI 00007d98 c3 return 00007d99 (O) install16 00007d99 c1 347 02 upshift 2 to DI 00007d9c 81 307 00 84 0b 00 + IDT16 to DI 00007da2 e8 1a 00 00 00 call schmegment 00007da7 89 007 = A to @ DI 00007da9 c3 return 00007daa (O) twitch32unP 00007daa 120 push A 00007dab 8b 005 50 8a 0b 00 = @ 756304 to A 00007db1 100 1+ A 00007db2 89 005 50 8a 0b 00 = A to @ 756304 00007db8 130 pull A 00007db9 66 otheroperandsize 00007dba cf dismiss 00007dbb (O) IDT32unPpointer 00007dbb 00 04 00 80 0b 00 00007dc1 (O) schmegment 00007dc1 123 push B 00007dc2 89 303 = A to B 00007dc4 c1 353 10 downshift 16 to B 00007dc7 81 340 ff ff 00 00 AND 65535 to A 00007dcd c1 343 1c upshift 28 to B 00007dd0 09 330 OR B to A 00007dd2 133 pull B 00007dd3 c3 return ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 8:44 The Well-Factored 386 Rick A. Hohensee @ 2003-07-28 14:06 ` David S. Miller 2003-07-28 16:36 ` hp 2003-07-28 20:33 ` Rick A. Hohensee 0 siblings, 2 replies; 32+ messages in thread From: David S. Miller @ 2003-07-28 14:06 UTC (permalink / raw) To: Rick A. Hohensee; +Cc: linux-kernel, linux-assembly On Mon, 28 Jul 2003 04:44:56 -0400 "Rick A. Hohensee" <rickh@capaccess.org> wrote: > The four actual main modes of the 386 Please stop making off-topic postings. If you continue to do so I will have to yank you from the lists at vger.kernel.org and filter you from sending emails to the lists. Thank you. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 14:06 ` David S. Miller @ 2003-07-28 16:36 ` hp 2003-07-28 20:33 ` Rick A. Hohensee 1 sibling, 0 replies; 32+ messages in thread From: hp @ 2003-07-28 16:36 UTC (permalink / raw) To: David S. Miller, Rick A. Hohensee; +Cc: linux-kernel, linux-assembly though probably not always that enlightning as announced, I certainly would not consider those artices 'off topic'. - i fact, despite i don't understand a word of those silly idiomatic texts, sometimes, i found the latest one quite interesting and, tightly reated to 'assembly' . any attempt to trying to documenting on the rsp. cpu should be regarded "on-topic", what else...! and, no #reader# (as opposed to some until now un-known, sort of 'maintainer') seems to have felt offended so there is no reason to that rude admonition. for instance, i would find those overly repeated, stupid questions about some obscure 'real mode' in linux (or for access to #the# graphic memory) much more annoying and accordinly "off topic" - if i would, at all. or, were you trying to cut down a bit on the tremendous traffic in this group? what a great relief... thanks + regards, hp David S. Miller am Montag, 28. Juli 2003 15:06: > On Mon, 28 Jul 2003 04:44:56 -0400 > > "Rick A. Hohensee" <rickh@capaccess.org> wrote: > > The four actual main modes of the 386 > > Please stop making off-topic postings. If you continue to do > so I will have to yank you from the lists at vger.kernel.org > and filter you from sending emails to the lists. > > Thank you. > - > To unsubscribe from this list: send the line "unsubscribe linux-assembly" > in the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de FAQ(s) + DOCs at http://linuxassembly.org pse, reply to << lx -at- lxhp -dot- in-berlin -dot- de >> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 14:06 ` David S. Miller 2003-07-28 16:36 ` hp @ 2003-07-28 20:33 ` Rick A. Hohensee 2003-07-28 20:33 ` David S. Miller 1 sibling, 1 reply; 32+ messages in thread From: Rick A. Hohensee @ 2003-07-28 20:33 UTC (permalink / raw) To: David S. Miller; +Cc: linux-kernel, linux-assembly >davem@redhatmicrosoft.CON >Please stop making off-topic postings. If you continue to do >so I will have to yank you from the lists at vger.kernel.org >and filter you from sending emails to the lists. > >Thank you. >- Rick Hohensee July 2003 Why, Rick? WHY? This is /Ha3sm/blurb on my box, where this originated. Ha3sm is an OS project written in osimplay, which is an assembler I wrote entirely in GNU Bash. Ha3sm is hoped to eventually be a complete computer operating system with a design emphasis on the local "console" user. Forth/AmigaDos first, server stuff second. I wrote osimplay for several reasons. First of all, I couldn't stop laughing when it occured to me that I could write a 386 assembler in Bash. So I did it. I'm still quite amused by it. There are utterly serious reasons for such a thing, however. Interdependancies of software packages are pernicious. Eventually you get to where you can't change anything, and you have to have everything for anything to work. Most Linux distros are like that now. You can't downsize Red Hat. Highly un-unix, in my opinion. You have to start with kernel sources and work up. I did so with cLIeNUX. Linux people think unix collapses without Perl. I don't have Perl in $PATH, and it's not in a cLIeNUX Core package. For what, writing an assembler? I don't mean to single out Larry Wall. Perl is only quantitatively worse in this regard than most other unix apps. Assume a unix, and you assume a lot of stuff. Well, when you want to write something original, most of that stuff is just in your way. Looking at the sh history in my devel vt, I use Lynx for a file browser, Pico, grep, less, cat and a couple other stone-stock doodads. An assembler in Bash is the lowest-level programming done from the highest level. Directly. No funny libraries. No middleman. No toolchains. Trivial portablility issues. Near-zero "install" issues. Get about your actual business, writing machine code. Which, by the way, is your actual business when writing, say, C. Or other arbitrary binary data. Perl is also a good example of what they give people to learn programming. Java, etc. also. The problem there is you are learning abstractions. With assembly you are learning how a computer actually works. With 386 assembly in 2003 you are learning how several hundred million desktop machines and laptops actually work at thier core. The 386 is ugly, but it's a fairly generic register machine, and most of what you learn about it applies to other register machines. Well, if you're selective. Ignore AAA, for example. This is what you need to know to ever do anything fundamental, and in fact is what you need to know to use the abstractions well. Bell Labs still uses C for Plan 9, but they wrote C. You can see in the exquisite Plan 9 code that when they write something in C they can see what it's exact machine code ramifications are. This is mastery, and it is a bottom-up thing. It's also really writing assembly. Ken Thompson wrote the original UNIX kernel, and ed, which are the two programs that define unix, in my opinion. The original ed was in PDP assembly. (So was the kernel). The PDP had about as many different branch conditions as a 386, i.e. 4 or 5 flags and branches on all of them plus some combinations of them. Thompson used most if not all of those branch conditions in ed. By hand. That's the sort of sight that can give somebody that believes Chuck Moore (Forth) is The One True UberCoder a crisis of faith. When somebody like Thompson (a tiny group, I admit) writes C, it just looks like they're writing C. Even if you don't have the next Forth or UNIX in you, you need to know assembly to master programming, be it Forth, C, ml, Lisp or whatever. Period. High Level Languages have not lived up to the hopes for them. Period. Things like Java are for building technology bubbles. Torvalds is Torvalds because he wrote all the assembly Minix needed for pmode. C is the lingua franca of the Internet because it's as low-level as it can be and still claim to be high-level, or "portable". C produces snappy application code. That's where it beats a public domain Forth, and commercial Forths are, well, commercial. Like, you can't reuse the parts like you can with a homebrew. You can write an OS in C, which was it's original striking achievement. People didn't write OSes in high-level languages in 1972. Well, they still don't. Plan 9 has very little assembly in it, but that's Bell Labs. They note that Plan 9 is an experiment. And it still has some assembly at crucial junctures. And those guys see the assembly under (int *)(bla()****) or what-the-hell as they are writing it. BSD has more, and 386 Linux is ludicrous for asm("") and setup.S and so on. And the difficulty and non-portability of e.g. GNU C asm("") offsets fully all the joys <cough> of C, for OS devel. So in realistic terms, operating systems are written in assembly. osimplay does not attempt to pretend otherwise. There are some stand-alone Forths out there, which you extend in Forth, but the Forths are in assembly, if they're not on Forth hardware. What osimplay does do is make assembly as easy as possible. The rush to the high-level mirage has left assembly stuck in 1965. This is the opportunity osimplay jumps on. There's enough suffering in the world without having to pretend 386 instructions are different depending on if you are in rmode or pmode. They are the same opcode. In osimplay they are the same mnemonic. With a prefix, they are the same action. And mnemonics actually are mnemonic in osimplay. The most central piece of data in a PC is called "A" in osimplay, not %eax/%ax/%al. Et cetera. osimplay also deliberately violates the unix ideal of lots of small tools. That's a good model except as pertains to your command interpreter. The shell is not a tool; it is your hands. osimplay is a shell script of a machete. Any competent campesino from anywhere can build Noah's Ark with it. Also, osimplay isn't a violation of the historical unix ideal of modularity to anything approaching the extent of the typical major GNU/Linux distro. Martin Richards wrote BCPL back in 1967 or so. In circa 1970 Thompson and Ritchie bailed on a FORTRAN compiler for UNIX and settled for an interpreted BCPL, B. Then Ritchie Pascalified BCPL into C. A little later Richards wrote the predecessor of Amigados in BCPL, Tripos. Martin Richards still works on a descendant of BCPL, MCPL. It has some nifty ml-like "patterns" case-construct compiler stuff, which MCPL uses for most of its program flow control, but it still doesn't have typed data ala C. Richards had a better idea, which idea also found its way into the ANSI Forth spec, cells. A machine has a cell size. That's your integer. Data type game over. I wrote a 3-stack Forth called H3sm to have a variable-size cell at the lowest level possible, i.e. demonstrably feasible in hardware. In H3sm they are called pytes. In osimplay, they are once again simply "cells", but they smooth over a lot of INTeL ugliness about rmode/pmode, and I presume, IA64. I'm more severely minimalist about some things than even Chuck Moore though. Pytes reduce the overall namespace proliferation of Forth, which is pretty bad. Also, I don't do do/while, for/next and so on in osimplay. GOTO gets a bad rap, but it's what actually exists, and it's unambigious. I don't believe the if/else/else issues are any worse in assembly than in C. Or Forth. "if" is "when" in osimplay though, just to avoid a conflict with the shell. I do provide an execution array widget in osimplay, and it's pretty snappy. There are reentrant procedure thingies and so on also. The idea of structured programming is nice. Somebody noticed that a few particlar conditional constructs are a complete set, and decided to make some hay trying to limit the world to those few constructs. Your PC is a big jump-table though, known as the IDT, and the OS is the program that deals with it. osimplay provides an execution array assembler with the osimplay words xray and yarx. It's not structured. It screams. Assembly is considered unportable and C is considered portable. I've already noted that the portable parts of C are the less crucial parts, and 386 assembly is only 100% portable to several hundred million machines, But, There's More. What machine is = A to B for? That's osimplay for what is MOV %eax, %ebx in Gas. That can be emulated trivially on any register machine with two or more registers. Among the machines the 386 is comparable to, the 386 constitutes a register subset that can be mapped onto the other device easily. There are other issues and tricks to solve them. What osimplay calls plurals, the REP thingies on the 386, can easily be hidden, and so on. For another example of this sort of thing, but going the other way, the Plan 9 assembler fakes COPY <memloc> to <memloc> on the 386, so the assembler is more CISCy. Plan 9 seems to have originated on a 68020. (The 386 only allows memory-to-memory in a few circumstances, like where SI and DI are already set up for LODS). I still think Chuck Moore has obsoleted register machines. I don't happen to have a stack-machine PC yet, however. Hence Ha3sm. I like my pytes, in H3sm. They will return to Ha3sm eventually, and Ha3sm will model the PC I wish I had, on a clone, Lord willin and the river don't rise. The bad news is, osimplay is of course ridiculously slow. It takes like 10 minutes to assemble a VGA font, with no high-ASCII glyphs. Converting a binary string to a byte is not what Bash likes to do. A 1400 byte femto-kernel takes like 30 seconds on a P166. Small price to pay for significantly lower mental burdens while actually coding the stuff, easily. Checkmate leaves no weaknesses. And things like fonts don't have to be reassembled every 10 minutes when you're working on the IDT. Also, since writing the preceding lines of this paragraph I made an array of semi-graphic binary-like names for 0-255, and fonts assemble now about as fast as code. 3 is $______II. The joy of scripting. There are several defenses from the slowness of osimplay. A: In an OS context, get onto the target machine as early as possible, with a Forth or other machine monitor of some kind. B: The first predecessor of osimplay was asmacs, m4 macros for gas. If you want to write a big app in osimplay for a GNU/Linux, an asmacs won't bite you too hard. Less than installing gcc. I'd rather deal with the slowness of sh though. C: osimplay doesn't have a linker, but it could benefit tremendously from one that could link to binaries that don't get reassembled on every development run, such as fonts. There are some predecessors of a linker in the ELF stuff in osimplay for Linux and the Cat thing at the end of Ha3sm/code/top. In fact, it should be possible to only reassemble the parts of an osimplay project that are currently under development, and keep those parts to hundreds of bytes of code. This blurb may come with several different subsets of the other things I have in this directory, or I may just do the Ha3sm/osimplay funpack. In that case you should get a target-systems-only osimplay, a Linux-apps osimplay with ELF and syscalls, a couple demo utils for Linux, a couple VGA fonts, a couple boot demos including a Forreal Mode demo and maybe a Squeal Mode demo, html manpage-like osimplay docs, and my re-edit of 386INTEL.TXT, converted about halfway to my programming style, and converted all the way to 80 columns or less, 7-bit ASCII only. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 20:33 ` Rick A. Hohensee @ 2003-07-28 20:33 ` David S. Miller 2003-07-28 22:27 ` Stephan von Krawczynski 2003-07-29 0:17 ` Brian Raiter 0 siblings, 2 replies; 32+ messages in thread From: David S. Miller @ 2003-07-28 20:33 UTC (permalink / raw) To: Rick A. Hohensee; +Cc: linux-kernel, linux-assembly On Mon, 28 Jul 2003 16:33:58 -0400 "Rick A. Hohensee" <rickh@capaccess.org> wrote: > Rick Hohensee July 2003 > > Why, Rick? WHY? Rick, I wish you luck finding another machine with lists to infiltrate. Because you're not going to do it on vger.kernel.org any more. Bye bye. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 20:33 ` David S. Miller @ 2003-07-28 22:27 ` Stephan von Krawczynski 2003-07-28 22:30 ` David S. Miller 2003-07-28 23:11 ` viro 2003-07-29 0:17 ` Brian Raiter 1 sibling, 2 replies; 32+ messages in thread From: Stephan von Krawczynski @ 2003-07-28 22:27 UTC (permalink / raw) To: David S. Miller; +Cc: rickh, linux-kernel, linux-assembly On Mon, 28 Jul 2003 13:33:00 -0700 "David S. Miller" <davem@redhat.com> wrote: > On Mon, 28 Jul 2003 16:33:58 -0400 > "Rick A. Hohensee" <rickh@capaccess.org> wrote: > > > Rick Hohensee July 2003 > > > > Why, Rick? WHY? > > Rick, I wish you luck finding another machine with lists to > infiltrate. > > Because you're not going to do it on vger.kernel.org any more. > Bye bye. Dave, I have to tell you I don't like your attitude shown in this case. Surely you can argue Rick does not really stay on a specific topic, but on the other hand he does not really flood the list, does he? I mean, compared to (name deleted)s' PR bubbles he is really low volume. Besides I have not read any complaints (1 pro) - only yours. Which leads me to think you kill him only because you don't like the man - and not really because of his writing - and because you _can_. This does not feel alright for me. Don't get me wrong, I am no Rick-fan, I don't know him and have no idea why he is really talking about his favourite topics. But I honour his right to speak up just like anybody else, even if it looks more like a "brainstorming" than constructive talking. Regards, Stephan ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 22:27 ` Stephan von Krawczynski @ 2003-07-28 22:30 ` David S. Miller 2003-07-28 22:58 ` David D. Hagood ` (2 more replies) 2003-07-28 23:11 ` viro 1 sibling, 3 replies; 32+ messages in thread From: David S. Miller @ 2003-07-28 22:30 UTC (permalink / raw) To: Stephan von Krawczynski; +Cc: rickh, linux-kernel, linux-assembly On Tue, 29 Jul 2003 00:27:37 +0200 Stephan von Krawczynski <skraw@ithnet.com> wrote: > I have not read any complaints (1 pro) People send me complaints about him every time he posts. And I don't care if you don't like my attitude, my job as list manager is not to be liked by people or to have them like my attitude. My job is to keep the lists clean. I told people last week that I was going to start cracking down on this. And I was absolutely serious. I know that linux-kernel is often a very unnice place to be subscribed, and I am going to change that. I publicly asked him NICELY to stop his postings, and he responded with his description of why his x86 assembler written in bash is so great. I have zero sympathy for people who act that way. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 22:30 ` David S. Miller @ 2003-07-28 22:58 ` David D. Hagood 2003-07-29 14:32 ` Timothy Miller 2003-07-29 0:34 ` jw schultz 2003-07-29 8:45 ` hp 2 siblings, 1 reply; 32+ messages in thread From: David D. Hagood @ 2003-07-28 22:58 UTC (permalink / raw) To: David S. Miller; +Cc: linux-kernel, linux-assembly David S. Miller wrote: > And I don't care if you don't like my attitude, my job as > list manager is not to be liked by people or to have them > like my attitude. My job is to keep the lists clean. I'd just like to say "BRAVO SIR!" I am glad to see you doing this, and I support your actions 100%. Anybody's right of freedom of speech ends when they force the unwilling to listen - this troll was -10, Offtopic. He was not talking about the kernel, any development of interest to the kernel, and I for one am glad he is getting bounced. Let him post his drivel-scribblings on Slashdot, along with goatse.cx, the porn trolls, and the *BSD is dead trolls. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 22:58 ` David D. Hagood @ 2003-07-29 14:32 ` Timothy Miller 2003-07-29 17:21 ` hp 0 siblings, 1 reply; 32+ messages in thread From: Timothy Miller @ 2003-07-29 14:32 UTC (permalink / raw) To: David D. Hagood; +Cc: David S. Miller, linux-kernel, linux-assembly David D. Hagood wrote: > David S. Miller wrote: > >> And I don't care if you don't like my attitude, my job as >> list manager is not to be liked by people or to have them >> like my attitude. My job is to keep the lists clean. > > > I'd just like to say "BRAVO SIR!" I am glad to see you doing this, and I > support your actions 100%. > > Anybody's right of freedom of speech ends when they force the unwilling > to listen - this troll was -10, Offtopic. He was not talking about the > kernel, any development of interest to the kernel, and I for one am glad > he is getting bounced. > > Let him post his drivel-scribblings on Slashdot, along with goatse.cx, > the porn trolls, and the *BSD is dead trolls. I personally have made more than my fair share of off-topic posts. Some of them have been filtered, which really doesn't bother me, because, well, they were off-topic. Sometimes, I get carried away, but I do keep in mind that off-topic posts can be very rude. I remind myself of this out of respect for others on the list. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-29 14:32 ` Timothy Miller @ 2003-07-29 17:21 ` hp 0 siblings, 0 replies; 32+ messages in thread From: hp @ 2003-07-29 17:21 UTC (permalink / raw) To: Timothy Miller, David D. Hagood Cc: David S. Miller, linux-kernel, linux-assembly could you pse keep that 'discussion' to where it belongs?! it is definitely 'off topic' in the "linux-assembly" mailing list. and, it is ridiculous, since it already generated much (M U C H) more traffic than the messages you're just complaining about. - so you should eliminate yourself, consequently, from that 'clean' list of yours -???- you complaint it is un-just - or did you, for instance, eliminate the owner of <rms@gnu.org> from your lk-devel list, too? who already emanated so many messages which have nothing to do with linux kernel devel that Rick would never be able to make up for that much of nonsense. best, hp Timothy Miller am Dienstag, 29. Juli 2003 15:32: > David D. Hagood wrote: > > David S. Miller wrote: > >> And I don't care if you don't like my attitude, my job as > >> list manager is not to be liked by people or to have them > >> like my attitude. My job is to keep the lists clean. > > > > I'd just like to say "BRAVO SIR!" I am glad to see you doing this, and I > > support your actions 100%. > > > > Anybody's right of freedom of speech ends when they force the unwilling > > to listen - this troll was -10, Offtopic. He was not talking about the > > kernel, any development of interest to the kernel, and I for one am glad > > he is getting bounced. > > > > Let him post his drivel-scribblings on Slashdot, along with goatse.cx, > > the porn trolls, and the *BSD is dead trolls. > > I personally have made more than my fair share of off-topic posts. Some > of them have been filtered, which really doesn't bother me, because, > well, they were off-topic. > > Sometimes, I get carried away, but I do keep in mind that off-topic > posts can be very rude. I remind myself of this out of respect for > others on the list. > > - > To unsubscribe from this list: send the line "unsubscribe linux-assembly" > in the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de FAQ(s) + DOCs at http://linuxassembly.org pse, reply to << lx -at- lxhp -dot- in-berlin -dot- de >> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 22:30 ` David S. Miller 2003-07-28 22:58 ` David D. Hagood @ 2003-07-29 0:34 ` jw schultz 2003-07-29 1:27 ` Alan Cox 2003-07-29 8:45 ` hp 2 siblings, 1 reply; 32+ messages in thread From: jw schultz @ 2003-07-29 0:34 UTC (permalink / raw) To: linux-kernel On Mon, Jul 28, 2003 at 03:30:55PM -0700, David S. Miller wrote: > On Tue, 29 Jul 2003 00:27:37 +0200 > Stephan von Krawczynski <skraw@ithnet.com> wrote: > > > I have not read any complaints (1 pro) > > People send me complaints about him every time he posts. > And I don't care if you don't like my attitude, my job as > list manager is not to be liked by people or to have them > like my attitude. My job is to keep the lists clean. > > I told people last week that I was going to start cracking down on > this. And I was absolutely serious. I know that linux-kernel is > often a very unnice place to be subscribed, and I am going to change > that. > > I publicly asked him NICELY to stop his postings, and he responded > with his description of why his x86 assembler written in bash is so > great. I have zero sympathy for people who act that way. Good for you! It took me a few minutes to figure out who you were talking about because he's been in my killfile for a while. He contributes NOTHING. Even RMS's cries in the wilderness on BK and how we shouldn't call linux, linux have more value. Now if we could cut off the threads about BK (as opposed to bk servers) started by anyone other than Larry... -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-29 0:34 ` jw schultz @ 2003-07-29 1:27 ` Alan Cox 2003-07-29 3:49 ` Larry McVoy 0 siblings, 1 reply; 32+ messages in thread From: Alan Cox @ 2003-07-29 1:27 UTC (permalink / raw) To: jw schultz; +Cc: Linux Kernel Mailing List On Maw, 2003-07-29 at 01:34, jw schultz wrote: > Now if we could cut off the threads about BK (as opposed to > bk servers) started by anyone other than Larry... Even better - by Larry too, excepting when its kernel relevant like downtimes, updates etc ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-29 1:27 ` Alan Cox @ 2003-07-29 3:49 ` Larry McVoy 2003-07-29 4:25 ` Gene Heskett ` (3 more replies) 0 siblings, 4 replies; 32+ messages in thread From: Larry McVoy @ 2003-07-29 3:49 UTC (permalink / raw) To: Alan Cox; +Cc: jw schultz, Linux Kernel Mailing List On Tue, Jul 29, 2003 at 02:27:32AM +0100, Alan Cox wrote: > On Maw, 2003-07-29 at 01:34, jw schultz wrote: > > Now if we could cut off the threads about BK (as opposed to > > bk servers) started by anyone other than Larry... > > Even better - by Larry too, excepting when its kernel relevant like > downtimes, updates etc Dave and Linus cc-ed me on the vger crackdown discussions and I offered to unsubscribe from the kernel list if it would help. Dave's comment was that I don't start the wars, which is probably true. I tend to respond to attacks, not go looking for fights. I'd be curious to know when it is that you think I've started a flame fest here, Alan. I'm here for two reasons, I like OS topics and I want to support BK. That latter one is a problem, the same character traits which make me want to help people when they have problems are the ones that make me participate in the BK flames. If the kernel community is ready to operate on a lower level of support from us, I'll bow out. It hasn't been pleasant being here for the last couple of years and I'd prefer to be gone. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-29 3:49 ` Larry McVoy @ 2003-07-29 4:25 ` Gene Heskett 2003-07-29 4:42 ` jw schultz ` (2 subsequent siblings) 3 siblings, 0 replies; 32+ messages in thread From: Gene Heskett @ 2003-07-29 4:25 UTC (permalink / raw) To: Larry McVoy, Alan Cox; +Cc: jw schultz, Linux Kernel Mailing List On Monday 28 July 2003 23:49, Larry McVoy wrote: >On Tue, Jul 29, 2003 at 02:27:32AM +0100, Alan Cox wrote: >> On Maw, 2003-07-29 at 01:34, jw schultz wrote: >> > Now if we could cut off the threads about BK (as opposed to >> > bk servers) started by anyone other than Larry... >> >> Even better - by Larry too, excepting when its kernel relevant >> like downtimes, updates etc > >Dave and Linus cc-ed me on the vger crackdown discussions and I > offered to unsubscribe from the kernel list if it would help. > Dave's comment was that I don't start the wars, which is probably > true. I tend to respond to attacks, not go looking for fights. > I'd be curious to know when it is that you think I've started a > flame fest here, Alan. > >I'm here for two reasons, I like OS topics and I want to support BK. >That latter one is a problem, the same character traits which make >me want to help people when they have problems are the ones that > make me participate in the BK flames. If the kernel community is > ready to operate on a lower level of support from us, I'll bow out. > It hasn't been pleasant being here for the last couple of years > and I'd prefer to be gone. As I've been lurking here for a while, I can appreciate that ones skin gets a bit tender after a while Larry. OTOH, your replies have helped a lot of us lurkers to see a much more balanced view of the so-called argument. Without your input, there aren't too many other voices to stand up and be counted. FWIW, (not much I'm afraid) I'm on your side. If the others want to do a similar program then they know what they want it to do and they should go ahead and write it, but IMO the users interface shouldn't be beholden to *anything* BK does. If their offering is a better offering than BK, so be it, we'll have YACVS. But, do it from a clean room, based only on what the programmer thinks is important, not on something that attacks your program, and even depends on it to be usefull. In other words, stick around and balance the scales from time to time. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-29 3:49 ` Larry McVoy 2003-07-29 4:25 ` Gene Heskett @ 2003-07-29 4:42 ` jw schultz 2003-07-29 12:04 ` Alan Cox 2003-07-29 14:55 ` Timothy Miller 3 siblings, 0 replies; 32+ messages in thread From: jw schultz @ 2003-07-29 4:42 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Larry McVoy, Alan Cox On Mon, Jul 28, 2003 at 08:49:41PM -0700, Larry McVoy wrote: > On Tue, Jul 29, 2003 at 02:27:32AM +0100, Alan Cox wrote: > > On Maw, 2003-07-29 at 01:34, jw schultz wrote: > > > Now if we could cut off the threads about BK (as opposed to > > > bk servers) started by anyone other than Larry... > > > > Even better - by Larry too, excepting when its kernel relevant like > > downtimes, updates etc > > Dave and Linus cc-ed me on the vger crackdown discussions and I offered > to unsubscribe from the kernel list if it would help. Dave's comment was > that I don't start the wars, which is probably true. I tend to respond > to attacks, not go looking for fights. I'd be curious to know when it is > that you think I've started a flame fest here, Alan. > > I'm here for two reasons, I like OS topics and I want to support BK. > That latter one is a problem, the same character traits which make > me want to help people when they have problems are the ones that make > me participate in the BK flames. If the kernel community is ready to > operate on a lower level of support from us, I'll bow out. It hasn't > been pleasant being here for the last couple of years and I'd prefer > to be gone. As the one who made the comment that Alan (tongue in cheek, i hope) reacted to, let me say that your posts have been welcome except when someone is pushing your buttons. When the topic has been about code your comments have been informative. Perhaps if the BK and licensing flame-fests are interdicted things will become a bit more pleasant for you. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-29 3:49 ` Larry McVoy 2003-07-29 4:25 ` Gene Heskett 2003-07-29 4:42 ` jw schultz @ 2003-07-29 12:04 ` Alan Cox 2003-07-29 14:55 ` Timothy Miller 3 siblings, 0 replies; 32+ messages in thread From: Alan Cox @ 2003-07-29 12:04 UTC (permalink / raw) To: Larry McVoy; +Cc: jw schultz, Linux Kernel Mailing List On Maw, 2003-07-29 at 04:49, Larry McVoy wrote: > Dave and Linus cc-ed me on the vger crackdown discussions and I offered > to unsubscribe from the kernel list if it would help. Dave's comment was > that I don't start the wars, which is probably true. I tend to respond > to attacks, not go looking for fights. I'd be curious to know when it is > that you think I've started a flame fest here, Alan. I'd agree entirely with that comment. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-29 3:49 ` Larry McVoy ` (2 preceding siblings ...) 2003-07-29 12:04 ` Alan Cox @ 2003-07-29 14:55 ` Timothy Miller 3 siblings, 0 replies; 32+ messages in thread From: Timothy Miller @ 2003-07-29 14:55 UTC (permalink / raw) To: Larry McVoy; +Cc: Alan Cox, jw schultz, Linux Kernel Mailing List Larry McVoy wrote: > If the kernel community is ready to > operate on a lower level of support from us, I'll bow out. It hasn't > been pleasant being here for the last couple of years and I'd prefer > to be gone. I'd rather you stayed. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 22:30 ` David S. Miller 2003-07-28 22:58 ` David D. Hagood 2003-07-29 0:34 ` jw schultz @ 2003-07-29 8:45 ` hp 2 siblings, 0 replies; 32+ messages in thread From: hp @ 2003-07-29 8:45 UTC (permalink / raw) To: David S. Miller, Stephan von Krawczynski Cc: rickh, linux-kernel, linux-assembly David S. Miller am Montag, 28. Juli 2003 23:30: > On Tue, 29 Jul 2003 00:27:37 +0200 > > Stephan von Krawczynski <skraw@ithnet.com> wrote: > > I have not read any complaints (1 pro) > > People send me complaints about him every time he posts. > And I don't care if you don't like my attitude, my job as > list manager is not to be liked by people or to have them > like my attitude. My job is to keep the lists clean. > > I told people last week that I was going to start cracking down on > this. And I was absolutely serious. I know that linux-kernel is would you, please, explain what you have to do with the 'linux-assembly' mailing list?! Date: Mon, 28 Jul 2003 15:30:55 -0700 From: "David S. Miller" <davem@redhat.com> To: Stephan von Krawczynski <skraw@ithnet.com> Cc: rickh@capaccess.org, linux-kernel@vger.kernel.org, linux-assembly@vger.kernel.org Subject: Re: The Well-Factored 386 > often a very unnice place to be subscribed, and I am going to change > that. > > I publicly asked him NICELY to stop his postings, and he responded > with his description of why his x86 assembler written in bash is so > great. I have zero sympathy for people who act that way. > - > To unsubscribe from this list: send the line "unsubscribe linux-assembly" > in the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de FAQ(s) + DOCs at http://linuxassembly.org pse, reply to << lx -at- lxhp -dot- in-berlin -dot- de >> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 22:27 ` Stephan von Krawczynski 2003-07-28 22:30 ` David S. Miller @ 2003-07-28 23:11 ` viro 1 sibling, 0 replies; 32+ messages in thread From: viro @ 2003-07-28 23:11 UTC (permalink / raw) To: Stephan von Krawczynski Cc: David S. Miller, rickh, linux-kernel, linux-assembly On Tue, Jul 29, 2003 at 12:27:37AM +0200, Stephan von Krawczynski wrote: > Dave, I have to tell you I don't like your attitude shown in this case. Tough. > is really talking about his favourite topics. But I honour his right to speak > up just like anybody else, even if it looks more like a "brainstorming" than > constructive talking. There is no right to speak using particular host. Dave _is_ admin of vger and he is not, AFAIK, bound by any contract regarding l-k. If you are unhappy with that - create and maintain a list of your own with whatever policies you happen to like; if somebody else will want to use it - more power to you. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: The Well-Factored 386 2003-07-28 20:33 ` David S. Miller 2003-07-28 22:27 ` Stephan von Krawczynski @ 2003-07-29 0:17 ` Brian Raiter 1 sibling, 0 replies; 32+ messages in thread From: Brian Raiter @ 2003-07-29 0:17 UTC (permalink / raw) To: linux-kernel, linux-assembly > Rick, I wish you luck finding another machine with lists to > infiltrate. > > Because you're not going to do it on vger.kernel.org any more. > Bye bye. I've no doubt that his posts seemed off-topic for linux-kernel, I would argue that they are certainly on-topic for linux-assembly. (I also imagine the latter sees much less traffic than the former, thus hp's comment.) I rather doubt that the complaints were coming from both lists, given that his stuff is far more interesting that the usual linux-assembly posts ("how do I write a number to screen without using BIOS?!") Assuming this is true, perhaps it would make more sense to allow him to continue posting to linux-assembly? b ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2003-07-30 14:05 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-28 16:02 The well-factored 386 Jack Dennon 2003-07-28 16:32 ` David S. Miller 2003-07-28 16:46 ` Andries Brouwer 2003-07-28 16:55 ` David S. Miller 2003-07-28 19:31 ` Herbert Pötzl 2003-07-28 19:41 ` Jamie Lokier 2003-07-29 11:14 ` Helge Hafting 2003-07-29 16:19 ` Jamie Lokier 2003-07-30 7:11 ` Helge Hafting 2003-07-30 14:05 ` Jamie Lokier -- strict thread matches above, loose matches on Subject: below -- 2003-07-29 12:59 John Bradford 2003-07-29 13:32 ` Ville Herva 2003-07-28 8:44 The Well-Factored 386 Rick A. Hohensee 2003-07-28 14:06 ` David S. Miller 2003-07-28 16:36 ` hp 2003-07-28 20:33 ` Rick A. Hohensee 2003-07-28 20:33 ` David S. Miller 2003-07-28 22:27 ` Stephan von Krawczynski 2003-07-28 22:30 ` David S. Miller 2003-07-28 22:58 ` David D. Hagood 2003-07-29 14:32 ` Timothy Miller 2003-07-29 17:21 ` hp 2003-07-29 0:34 ` jw schultz 2003-07-29 1:27 ` Alan Cox 2003-07-29 3:49 ` Larry McVoy 2003-07-29 4:25 ` Gene Heskett 2003-07-29 4:42 ` jw schultz 2003-07-29 12:04 ` Alan Cox 2003-07-29 14:55 ` Timothy Miller 2003-07-29 8:45 ` hp 2003-07-28 23:11 ` viro 2003-07-29 0:17 ` Brian Raiter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).