lkml.org 
[lkml]   [2004]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: my opinion about VGA devices
Blizbor wrote:

> Tomas Carnecky wrote:
>
>> Richard B. Johnson wrote:
>>
>>>> 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.
>>
> I think you're wrong.
> 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.

I don't think there is any way you can handle a crash at that stage,
either the kernel starts successfully or not.

>
> 1. What if kernel crashes during graphics driver initialisation ?

Developers can have a serial console attached to the computer and get
the info from there and any other user don't really care, I don't think
that the office workers in the Munich government would care about it and
send a bug report to the LKML.

> 2. What if you move HD to another box with totally diferrent graphics
> device ?

You could have two drivers compiled in, one very small and simple (VGA)
for the case that you'll change the computer and a boot parameter to
change them. But usually people compile a new kernel before putting the
HD into a new box so I don't see this as a a stong argument.

> 3. What if the kernel DO crash before graph.dev. initialisation ? How
> many hours you will spend diagnosing ?

Not even a minute, I'd switch to a driver version that worked before.
And maybe report that the new version doesn't work.

>
> 4. What if before or during graphisc driver initialisation a kind of
> delayed error in other device will occur ?

Not if you initialize the graph.dev. before any other device, as soon as
possible, just after the bus(PCI etc.) initialization.

tom

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.071 / U:4.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site