[lkml]   [1998]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Kernel videocard support YES or NO?
On Mar 28, Vojtech Pavlik wrote:

> Yes, I can only second this. I'll list a couple more reasons why graphic
> card support SHOULD be in the kernel:
> * In userspace you can't use interrupts, which some newer cards generate.
> (eg. Riva 128)

haven't seen any realy fact that you really _need_ interrupts and that
interrupts will improve performance and won't lower it due to costs
of interrupts. I don't know the Riva128 chip, but e.g. S3 chips have
very small coammnd FIFOs and here interrupts aren't worth.

> * In userspace you can't do DMA well, and DMA is very useful with never
> videocards and there are some whose performance would be poor without it.
> (eg. Pyramid 3D)

I have seen tests with S3 ViRGE chips using DMA in user-level code
to transfer images. performace tests showed it's not worth at all
(for this specific setup, of course YMMV -- but it's tecnically possible!).

> * In userspace it is not a good idea to do a cli(). It's a big stability
> risk. However, this is needed for many graphic cards to communicate with.

not true that is needed `for many graphic cards to communicate with'.
please check tecnical docs and X sources before inserting more and more
myths here :-(

> (You should cli() even for a standard VGA, because of at least one register
> that's flipflopping between index and data state.)

there is exacly one driver (called `The X Server [tm]) touching the graphics
chip, so this isn't needed. and if you're thinking about multiple threads
rendering simultaneously you'd need locking etc. no matter if you're running
in kernel or user mode.

> * In userspace you can't do good console switching, because many videocards
> (eg. SPEA Mirage P-64) have write-only registers, and with that it's
> impossible to properly save and restore video state when you don't have
> centralized support for it.

because of write-only registers you have to use fixed setup tables
for those registers (which will cause other problems).
again, this won't depend on user or kernel mode. either you run
something like SVGATextmode, or put this code in X server's exit handler,
or ...

> * In userspace you need to have root privileges to control the video
> subsystem, which inherits security and stability risks. (Eg. A buffer
> overflow in the application can give you root access)

so we need a much better security handling, priviledges shared libs
and much other things. but this isn't a topic for KGI because the
X server is not the only suid-root problem (at least not in my system;).

> * Acceleration support should be in the kernel, too, because most of the 3D
> accelerated cards use DMA, which can't be well used outside kernel, and, if
> done, must be restricted to root privileged user only, because it gives you
> a complete control of the system. Thus you'd need setuid graphic programs.

again, prove that it's usefull at all! and please don't claim it's not
possible in user mode with minimal kernel support.

I stop here trying to argue against all those "X can't ..." and
"GGI/kernel will be able...". just write the code and show
that it's that much better, safer, faster, than advertized for
a very long time and in may mails now and all users will happily
convert to GGI and vote for it. but now... ?!?!

All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \ ^^^^^ ^^^^^

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:42    [W:0.135 / U:1.908 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site