olafBuddenhagen@... wrote:
> Anyways, after I (probably badly) tried to explain the current situation
> with GGI, he seemed interested in some cooperation -- though I'm not
> sure how exactly he imagines it. However, he got pretty sceptical when I
> mentioned the kernel part, claiming that the kernel folks want as little
> as possible in the kernel. At the end Keith Packard also jumped in, and
> he is totally against mode setting in the kernel, on the ground that it
> is very complex and hard to get right etc.; and there should be some
> trusted agent in user space instead. IMHO a strange argument,
Right. However, if they absolutely think this is a good thing, it can be
done. It is awkward, though.
Very early KGI designs used a special manager application to load/save
graphics context (including screen content) to allow for totally
transparent VC-switching.
This application could as well have set up the new target modes.
However, I agree, that mode switching belongs in the kernel. Killer
arguments:
1. If we want a really secure SAK, we must be able to fully restore the
graphics card state to a sane point from which we can start a
textmode or graphical logon. This can only be done, if the mode setup
resides in kernel space.
Ideally _compiled in_ for it to work even in situations where the
system is quite broken (like HD failure).
2. This will also help tremendously, if you got a system with a messed
up graphics mode (which tends to happen e.g. when sleep-/suspend-modes
are activated, or when switching to/from X while using fbdev).
You can then remotely restore a sane state. Not by fiddling around
with SVGATextMode like stuff, but by just killing the faulty app or
sending a signal to the kernel driver.
3. Mode setup is not complicated at all. It is just pushing a few values
into a few registers. The most complicated thing about it is, to
figure out, which registers might influence mode setup and thus
need to be written to, just in case they carry strange values.
This is more of an issue with chipset documentation and the quality
of drivers that are reverse engineered.
It is mode negotiation (i.e. determining a mode that fits the needs
of monitor and application and is supported by the graphics card)
that is complicated. This can easily be moved out of kernel context.
4. Moving complex stuff out of kernelspace is done to allow for failure
without taking the system down. Access violation in userspace will
just kill that app. It can be restarted etc. In kernel, it will cause
an oops and maybe a panic.
However, this is not an issue for graphics mode setup:
Program logic for mode setup is really simple, if mode negotiation is
left aside. Kernel support could be shrinked down to a table of
"known modes" (filled in by some userspace mode negotiation daemon)
and a bunch of in/out/mem-access/barrier calls.
Yes, this can still kill the machine, if the values programmed cause
the GC to e.g. do a DMA transfer of zeroes to the entire RAM, or lock
up the PCI bus. But it doesn't quite matter, if you cause such
problems from user- oder kernelspace.
Even in the unlikely event, that there is an error in the program
logic that will cause a segfault during mode setup: What do you gain
from it being in userspace? You are likely to get a broken mode anyway,
thus defeating console use of the machine, which is in many scenarios
not much wirse than loosing it with a panic, as you can only blindly
try to shut it down and restart, then.
4. One of the kernels main function is to virtualize hardware. Graphics
hardware is about the only exception now. I don't think a graphics
controller reduced to mode setup functionality is so much more
complex than stuff like the HostAP drivers for simple WLAN cards.
Same goes for the IP stack.
Thus my $0.02 about graphics drivers and the kernel:
A) Mode setup needs to be in the kernel to allow for SAK and a nice and
simple integration with console switching.
B) Mode negotiation can be done outside the kernel. I don't quite care.
As I tend to like small kernels, I'd even favour to move it out.
C) The kernel part must make sure, that the graphics drivers cannot be
abused by the app accessing it. E.g. it must not be able to abuse
the cards DMA engine to gain access to protected memory, it must not
be able to write values into card registers that endanger system
stability (like overclocking), it must not be able to gain too much
access to other apps data (reading foreign parts of the graphics
memory).
Other than that I don't care much about how much of the drivers runs
where.
> considering that with fbdev there has been mode setting in the kernel
> for years, and this is extremely unlikely to change -- I don't see how
> the kernel console stuff would work relying on some user space agent for
> mode setting...
Right. It doesn't make much sense. It can be done, but it's utterly
complex for little to no gain.
CU, ANdy
--
= Andreas Beck | Email: <becka-sig-ggi@...> =
|