hmm...didn't seem off-topic to me.
Anything about 386 hardware would seem
to be rather closely related to Linux
assembly language programming.
[email protected]
On Mon, 28 Jul 2003 09:02:32 -0700
Jack Dennon <[email protected]> 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...
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.
On Mon, 28 Jul 2003 18:46:21 +0200
Andries Brouwer <[email protected]> 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.
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 <[email protected]> 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
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
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
> > 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.
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 --
[email protected]
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
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
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