Messages in this thread | | | Subject | Re: kill -9 <pid of X> | From | Jes Sorensen <> | Date | 16 Aug 1998 12:27:07 +0200 |
| |
>>>>> "Jon" == Jon M Taylor <taylorj@ecs.csus.edu> writes:
Jon> On 13 Aug 1998, Jes Sorensen wrote: >> >>>>> "Jon" == Jon M Taylor <taylorj@ecs.csus.edu> writes: >> Jon> But is has in fact done so, by allowing for driver-specific Jon> ioctls. That is one thing those ioctls be be used for. >> Its possible, but it was not the intention.
Jon> Nevertheless, it should work OK. kgicon drivers will Jon> implement KGI acceleration ioctls as fbcon ioctls, and the LibGGI Jon> fbdev display target will know how to use those ioctls for Jon> acceleration.
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.
>> Or something like libGGI.
Jon> LibGGI does not do any direct hardware access. Or did I Jon> misunderstand you?
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.
>> >> We did not do that on purpose, ioctl == context switch and we >> >> don't want that. >> Jon> direct userspace access to accel registers == unsafe. *I* don't Jon> want *that*. You can get quite acceptable speed out of ioctls. Jon> Not the most speed possible, but in most cases that isn't a Jon> concern. >> Sorry, tough.
Jon> Well, you already gave us the tool we need to do this.
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?
If you want 100% safety, buy proper hardware, don't try to fix things inside the kernel with a sledgehammer.
>> If you want to run X on broken hardware then you'll have to take >> the risk.
Jon> Not really. All I need to do is use fbcon with a kgicon Jon> accelerated driver, and then run XGGI using the fbdev display Jon> target. Should work just fine.
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.
>> A context switch is not acceptable here and much worse, it will >> require you to implement a zillion drivers for acceleration of >> various chipsets which will lead to unnecessary code bloat.
Jon> The drivers are already implemented - they are the KGI Jon> drivers. Through kgicon, I can use them with fbcon. No one else Jon> needs to care about those acceleration ioctls if they do not want Jon> to, and yet they can be used by usersapce code that knows about Jon> them. Best of both worlds.
No, you are ruining a valuable resource like libGGI by letting it depend on something that will hopefully never get included in the kernel.
Personally I am really sad about this, I thought things were moving in the right direction with fbdev on the PC now as well, seems not. According to what you are telling us, you just want to disguise KGI under abscon and then later use that as an argument to try and push the `real' KGI into the kernel using the argument that its already there.
How are you going to disguise EvStack?
Jes
- 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
| |