Re: my opinion about VGA devices

[Tomas carnecky]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/