From: James Simmons <jsimmons@edgeglobal.com>
  To  : ggi-develop <ggi-develop@eskimo.com>
  Date: Thu, 4 Feb 1999 09:35:26 -0500 (EST)

Re: [linux-fbdev] New fbcon patch - version 0.2 - against (fwd)

I though you might be interested in this email. I was think of placing
this on slashdot. I need to know the framebuffer archives address. I want
people to be able to follow the debate.

---------- Forwarded message ----------
Date: Thu, 4 Feb 1999 12:20:45 MET-1
From: Petr Vandrovec Ing. VTEI <VANDROVE@vc.cvut.cz>
To: James Simmons <jsimmons@edgeglobal.com>
Cc: linux-fbdev@vuser.vu.union.edu
Subject: Re: [linux-fbdev] New fbcon patch - version 0.2 - against  

Hello list readers,
   I'm sorry, that's my last post on this topic, but I think
that I must clear some things...

On  3 Feb 99 at 20:55, James Simmons wrote:
> > > Are video accels a computer resource like a floppy controller or CPU ?
> > They are something like FDC because of they cannot be shared, due to
> > limitations of the output device (FDC controls limited number of FDD,
> > so you have one /dev/fd? for one FDD;
> No. I'm talking about when you mount /dev/fd0. With  the proper
> permissions and mount you do have the floppy shared. People can go into
> that directory where you mounted the floppy.
Nothing prevents you from
1) share fb same way as fd is shared: if two writes to device, last wins.
   Of course, no synchronization occurs. With your ideas, if two peoples
   opens /dev/fd0, each of them has own diskette and kernel prompts
   for diskette change. And from this, first idea, comes first problem:
   who has permission to write to this virtualized copy of FDD and who
   has right to swap media in physical FDD.
2) building something like filesystem (for example, window manager) at the
   top of the framebuffer. But even in this case, last-who-writes wins.
   Same applies for non-virtualized /dev/fb and I do not see point, why
   /dev/fb should be virtualized.
> Yes lib doesn't have to stop a app from misbehaving. So linux is moving
> away from the traditional model of UNIX toward a Microsoft NT model. UNIX
> model is that the kernel manages the hardware and apps and libs talk to
> the kernel to use hardware resouces. Where with the Microsoft model the
> DLL handle all the hardware  issues. So linux will be M$ without the GUI.
> linux 5.0 -> libSCSI, libMmem, libIDE.
Why not? There is no reason to have everything in kernel. You need
1) you should be able to create an app,
2) one misbehaved app must not interfere with app of another user,
3) system must be able to alocate/release resources to apps.
That's all. Please, notice that (2) does talk about `another user',
one of your apps can send signals to another your apps without limits
and that (3) does not talk about neither sharing nor virtualization.
And why not have DLLs? You are watching problem from side: I've created
bug-free, superior driver for that hardware... I'm watching problem
from other side: I've created buggy driver and I wish to run it with
limited permission because of my SCSI contains important data for me.
If you ever wrote (big) program for some operating system running
only in kernel space (Netware 2.15-4.11 with exception of 4.10-addons),
you know that little mistake, which cannot cause anything in userspace,
brings whole system down very easily.
Also, there is 5-6 types of FDC around, but hundreds (I think thousands)
different video hardware around. So every FDC driver is tested by much
larger community than video driver. Also, FDC can read up to 5 types
of diskettes, but framebuffer is much more flexible.
> > No. Accelerator can have per-user interfaces (I think that some SGI
> > hardware has, maybe ...@....sgi.com can comment). And you do not access
[Jeff, thanks for your pointer, it is interesting reading which can clear
some things up, at least for me]
                                                   Best regards,
                                                       Petr Vandrovec
                                                       vandrove@vc.cvut.cz