All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomas Carnecky <tom@dbservice.com>
To: root@chaos.analogic.com
Cc: Oliver Neukum <oliver@neukum.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: my opinion about VGA devices
Date: Wed, 20 Oct 2004 17:01:08 +0200	[thread overview]
Message-ID: <41767DB4.9040008@dbservice.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0410201022370.12062@chaos.analogic.com>

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.

tom

  reply	other threads:[~2004-10-20 15:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-19 22:10 my opinion about VGA devices Tomas Carnecky
2004-10-20 11:18 ` Oliver Neukum
2004-10-20 12:31   ` Tomas Carnecky
2004-10-20 12:56     ` Richard B. Johnson
2004-10-20 14:14       ` Tomas Carnecky
2004-10-20 14:34         ` Richard B. Johnson
2004-10-20 15:01           ` Tomas Carnecky [this message]
2004-10-20 16:58             ` Matthew Garrett
     [not found]             ` <4178F276.2040501@globalintech.pl>
2004-10-22 11:58               ` Tomas carnecky
2004-10-22 19:13         ` Geert Uytterhoeven
2004-10-20 20:16     ` Oliver Neukum
2004-10-20 17:27 ` Kendall Bennett
2004-10-22  8:29   ` Helge Hafting
  -- strict thread matches above, loose matches on Subject: below --
2004-10-19 18:51 Tomas Carnecky
2004-10-23 16:11 ` Blizbor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41767DB4.9040008@dbservice.com \
    --to=tom@dbservice.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oliver@neukum.org \
    --cc=root@chaos.analogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.