Tomas Carnecky wrote:
Richard B. Johnson wrote:I think you're wrong.
Why do you let user-mode programs access the hardware directly?
You don't do this with network devices (there you have syscalls), you don't do this with sound devices (alsa).
Any root process can mmap() any of the memory-mapped hardware
including network devices. This isn't normally done because
handling interrupts from such hardware isn't very efficient
in user-mode, and redistributing data meant for another
process would be a nightmare. However, it can be done.
IMO it makes a proper power managment implementation impossible.
Wrong. The 'normal' user can't do such I/O, root can. See iopl(), which
sets the I/O privilege level. This has nothing to do with power-
management.
Power managment should be done in the kernel, that's why there is sysfs and the kobjects. But it can't be done properly if some process from user-mode (even root processes) do access the hardware directly.
Power managment isn't the only reason why it shouldn't be done, but also everything related to the device managment etc. There should always be a driver between a process and the hardware as a protection.
Last time I've tried a LiveCD distro I've seen a nice boot console with background picture, high resolution (1024x768) and nice small font. That means that the framebuffer driver had to be initialized at that time. I don't have framebuffer drivers compiled into my kernel so I don't know at which point these are initialized, but it must be at a quite early point in the boot process.
Even Fedora, which boots in a 'graphical' mode, really boots standard
text-mode until 'init' gets control. They just hide the console output
by setting the grub command-line parameter, "quiet".
The kernel messages are still available using `dmesg`. If you want
to eliminate any possibility of losing kernel messages because
the kernel failed to get up all the way, just use /dev/ttyS0 as
your console during boot.
Well... that's why I don't understand why we should keep the VGA code in the kernel. It's very unlikely that the kernel crashes before a graphics driver can be initialized (if you do this as soon as possible) unless you have a bad CPU etc.
This is not a good idea. In such important (should I say 'critical' ?) software like kernel
there is no room to developers 'probability sense'. If exists hypotethical situation that
something will go wrong it should be taken into account and a software way to handle it
must exist.
1. What if kernel crashes during graphics driver initialisation ?
2. What if you move HD to another box with totally diferrent graphics device ?
3. What if the kernel DO crash before graph.dev. initialisation ? How many hours you will spend diagnosing ?
4. What if before or during graphisc driver initialisation a kind of delayed error in other device will occur ?