Messages in this thread | | | Date | Sun, 16 Aug 1998 12:03:22 -0400 (EDT) | From | <> | Subject | Re: kill -9 <pid of X> |
| |
On 16 Aug 1998, Jes Sorensen wrote:
> Ahhh so thats why as few of you keep running around talking about > kgicon instead of just porting your drivers to become real fbcon > drivers. You have been told a million times here that acceleration > belongs in user space and still you insist on putting it in the kernel > where it does not belong.
I dunno, if it's a loadable module.. Who cares? If were just an abstract method of allowing userspace to quickly do accelleration it would be better..
The fact remains that PC video hardware is not senceabily built and the drivers really need to be in the kernel to do accelleration. There are lots of weird issues with trying to do accelleration, there is no way a process without all sorts of hardware access can do accelleration.
> I had the impression that people had finally realised the acceleration > belongs in user space and were now porting libGGI to use this - seems > like I was wrong ;-( Basically you are telling us that libGGI will > never be fast as it can never ustilize accelration - this is a real > shame.
No, he's saying that people who dont wish to use accelerated drivers with libGGI can never have acceleration on the current FBCON driver. You could write your own libggi target that banged the hardware and got acceleation.
> And now you are telling us that kgicon is useless and should never go > into the kernel - why do you keep wasting your valuable resources?
It should go into the kernel, thats the only place it can be multiplexed, used fully (irqs,dmas, atomic operations), and used safely.
It doesn't waste much valuable resources since it's modular.. Unless you think the video driver code should be swappable while it's in use.. If it were in user space the process using it would have to be mlocked and running with root privs..
Furthermore, the dumb frame buffer and the acceleration parts could be in seperate modules (they might already be I havn't used kgicon, of KGI in a long time).. You only get the acceleration functions loaded if you use an accelerate app..
> If you want 100% safety, buy proper hardware, don't try to fix things > inside the kernel with a sledgehammer.
Ok fine, I'll take your bet and double it. What PROPER hardware can I get for X86 that can do FULL ACCELERATION safely from userspace? It would need to have support for hardware context switches and be able to get steller performance without the use of DMAs or IRQs. AFIK there is NONE, and if there it it's not common..
> But again, you just told us that you want to use kgicon to bloat the > kernel with a ridiculous acceleration API which ought to never be > included in the kernel.
But again, you've wanted us to include various strange network drivers in the kernel which never outta be included in the kernel. :)
Come on, this isn't a microkernel here. It's monilithic. We include HARDWARE drivers in the kernel..
Does soundmodem need to be in the kernel? It needs to be there less then the acceleration stuff!
Soundmodem coulde be done with a userspace daemon which uses a slip link (ala diald) and talks to /dev/dsp. Though it prob wouldn't work on anything less then a PII 300.. It's just a performance hack having it in the kernel and it adds alot of code. But you and I just dont compile it in, so we dont care.
kgicon accelleration is much more then just a performance hack (though it's that too) and if you dont want it then dont use it..
From what I've seen libggi gives you TONS of choices.
> How are you going to disguise EvStack? > > Jes
As descent multihead support perhaps? It would be nice to see good multihead (/multi console) support on Linux. (yes, I know metrox and accelx give you multi head, but what if I want two consoles, one with two heads?)..
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |