comp.os.linux.development.system with
Quote:>And you think embedding a graphical de* in the kernel is a _good_
>idea???
It's a module so you don't have to have it in the kernel embedded.
Quote:>Did you consider the possibility that maybe that's a HORRIBLE idea,
No. Not yet. :) Another issue is that I also want to have an interface for
user mode debugging. I know there is GDB but I really don't like it. Though
there are some GUIs for it which help make it more usable I still don't really
like it.
Considering that SoftICE on Windows does quite well and is regarded as one of
the best de*s I think it would be great to have a similar tool for linux.
Quote:> -> The ones you introduce as a result of your de* being
> painfully complex;
It doesn't have to be painfully complex. But that depends on how I actually
have to implement it. BTW: This de* has been around for several years now
(http://www.veryComputer.com/) and it works. The only thing is that it doesn't
work with X so I wanted to fix that.
Quote:> -> The ones that result from any shortcomings in the implementations
> of the video cards;
AFAIK I only need access to video memory. Everything else could be done inside
my code. It's not as if I need some fancy graphics or such.
Quote:> -> The ones that result from any shortcomings in the perfection of
> your understanding of how the video cards function.
That's what have to be fixed. But every program has bugs in the beginning. If
it is longer around and propely maintained they will be fixed.
Quote:>Let's put it this way: The existing developers working on the kernel
>have never felt any need to resort to this sort of thing. They have
I guess there are many more people who want to have some decent de*
around.
Quote:>generally denigrated the thought of putting any extensive "graphical"
>functionality into the kernel.
That's why they put framebuffer support in the kernel, right? :)
Quote:>And remarkably enough, the results of THEIR efforts is an OS kernel
>that is sufficiently good that SCO representatives have been on public
>record that they consider it impossible that it could have gotten so
>robust without stealing code from SCO.
So what? I don't know what SCO has got to do with my de*? Apparently
there was a time without a decent kernel de* for Windows as well. People
also wrote great software at that time, but that doesn't mean that nobody will
appreciate it when there are better tools around.
Quote:>The notion that an inside-the-kernel graphical de* would help in
>this seems simply ridiculous.
Then you don't have to use it. If you don't like it, why bother?
Quote:>- The amount of work required would be enormous, and parts of it would
> be obsoleted the next time NVidia or ATI or whomever else come out
> with a new graphics chipset.
That's why I try to find an approach that is working as much as independently
of any special brand as possible. I don't like to have to support hundreds of
video cards and fix it every time a new one is around.
Quote:>- The quantity of code and memory allocation that would get forced
> into the kernel would be atrocious. You'd have a kernel 8MB,
> _compressed_, that won't run without having at least 128MB of RAM
> around.
Obviously a kernel de* has no use of being put directly into the kernel.
You load it on demand as a module because you surely don't want to have it
around all the time. Currently the module is about 200Kb big. Of course you
have to save the current display but it this is nowhere near 8MB what you are
talking of. And the code shouldn't expand that much to gain such a big size
either.
Quote:>I didn't think there was any Linux idea more preposterous than porting
>it to C++; I now stand corrected. There _is_ something more
>preposterous than that.
Thanks. :) Funny thing is that it is already done. I don't have to do it. I
just want to maintain it and improve it.
--
Gerhard Gruber
Fr jedes menschliche Problem gibt es immer eine einfache L?sung:
Klar, einleuchtend und falsch. (Henry Louis Mencken)