OLS and console rearchitecture

OLS and console rearchitecture

[Jon Smirl]

After talking to many people at OLS this seems to be the consensus for
rearchitecting fbdev/DRM. It has been proposed that this design be a
five year goal and there is still disagreement about the exact path to
get there.

This is a first pass for lkml people. I will incorporate comments and
repost for the final pass. I'm sure everyone will let me know if I've
misinterpreted some of the design points.

First a basic definition. There are two consoles, the kernel one
(printk, kdbg, OOPs, etc) and user one (normal console logins). In
Linux these are currently implemented with the same code. There may be
advantages to splitting the implementation in a future design.

1) PCI ROMs - these would be exposed via sysfs. A quirk is needed to
track the boot video device and expose the contents of C000:0 for that
special case. See the lkml thread: Exposing ROM's though sysfs, there
are already proposed patches.

2) VGA control - there needs to be a device for coordinating this. It
would ensure that only a single VGA device gets enabled at a time. It
would also adjust PCI bus routing as needed. It needs commands for
disabling all VGA devices and then enabling a selected one. This device
may need to coordinate with VGA console. You have to use this device
even if you aren't using VGA console since it ensures that only a
single VGA device gets enabled.
Alan Cox: what about hardware that supports multiple vga routers? do we
care?
JS: no design work has been done for this device, what would be it's
major/minor? would this be better done in sysfs?

3) Secondary card reset - Handled by an initial hotplug event. We need
a volunteer to write clean vm86 and emu86 apps for running the ROM
initialization. Resetting needs #1 and #2 to work since resetting a
card will enable it's VGA mode. I have an implementation of this but it
needs a lot of clean up.

4) DRM code reorganization. There were several requests to reorganize
DRM to more closely follow the Linux kernel guidelines. This
reorganization should occur before new features are added.

5) Multihead cards will expose one device file per head. Many IOCTLs
exposed by these devices will be common. Some, like mode setting, will
be per head.

6) Mode setting before early user space - this was decided to be a
platform specific problem. With minor adjustment the kernel can be made
to boot without printing anything except errors before early user space
starts. Platform specific code will need to handle these error messages
if any. This includes INT10, Openfirmware, mainframe serial consoles,
VGA mode. Suppressing informatory printing before early user space
starts allows a clean boot straight into graphics mode.

7) Mode setting from normal user space - devices will have a standard
IOCTL accepting a mode string like fbdev currently uses. This IOCTL
will lock the device and optionally trigger a hotplug mode event. Mode
setting for some fixed devices is simple enough to avoid the hotplug
event. In the hotplug event the mode line will be decoded, DDC queried,
etc. Some classes of devices (for example Intel 810,830,915) have to
have their mode set using vm86 and the video BIOS. Others might use a
small C app to query DDC and then use a device specific IOCTL to set
the mode registers. Early boot and normal user space will use the same
hotplug apps so they need to be as small as possible (good luck IA64
and emu86).

8) Merged fbmode - per head mode lists will include merged fb modes if
the other heads aren't in use. Setting a merged fb mode will lock out
the other head devices. It was decided that this was a better design
than having a control device.

9) printk - setting the mode will also record the fb location, size,
stride. Combining this info with the current fbconsole code will allow
printk/oops to print in all modes.

10) a new system console UI is proposed. SysReq blanks the current
screen and replaces it with the system console. System console will
also support runing kdbg. Hit SysReq again and whatever you were doing
is restored. This operation does not change the video mode.

11) OOPs will cause an immediate screen clear and painting of the
system console including the OOPs data. It is not needed to change the
video mode. Further drawing to the screen will be blocked until SysReq
returns to normal operation if possible.
Alan Cox: No consensus on the screen clear bit - there are actually
reasons to argue against it.
JS: Maybe save the contents at OOPs time and hotkey back to it? This
assumes the system is stable enough to do the copy and access the
keyboard. Another idea: start painting the OOPs from the top without
clearing, hope useful userspace data is at the bottom?
Nicolas Mailhot: Don't forget about power management, unblank the
screen and don't let it blank again since you may not get it back.
Graphics mode lets more OOPs info fit.

12) interrupt time printk - certain hardware implements
non-interruptible operations. Most modern hardware does not do this.
For older hardware these non-interruptible operations will need to be
wrapped by the device driver. The complete data needed to finish the
operation will be provided in the IOCTL. Doing this enables an
interrupt time printk to call into the driver, make sure the hardware
is free by completing the pending operation, and then write to the
framebuffer. No older hardware currently implements this protection;
without this protection there is potential for locking the machine.

13) all of the features being discussed are implemented by a single
device driver plus a supporting set of library drivers. Multitasking of
multiple controlling device drivers for a single piece of hardware is
not allowed.

14) A new framebuffer memory manager is needed for mesa GL support. Ian
is working on it. The memory manager will be part of the support
library driver code. 

15) Over time user space console will be moved to a model where VT's
are implemented in user space. This allows user space console access to
fully accelerated drawing libraries. This might allow removal of all of
the tty/vc layer code avoiding the need to fix it for SMP.

16) accelerated, kernel based console drivers are not easily written in
this model. The only in kernel operations are simple ones like
CR/scroll, clear, print text. It is possible to call existing DRM entry
points from a kernel thread, but the code needed is complex. Note that
only things like printk use this console so is there a real need for
acceleration?

17) A user space console implementation also makes supporting multiple
users on multiple heads/card easier. The kernel will not need to be
modified for multi-user VT support. User mode console allows pretty
text and Asian scripts.

18) A coordinated system for grouping console devices needs to be
designed. This will be bad if each distro does it differently. One
proposal is to use udev to create: /console/1/mouse,
/console/1/keyboard, /console/1/usb_hub, /console/2/mouse,
/console/3/keyboard, /console/4/usb_hub, etc.
Alan Cox: Another is to use namespace mounts

19) SAK - secure attention key. We forgot to talk about this so we need
a design.
Alan Cox: Falls straight out of having the kernel + helper mode setting

20) A PAM login would assign ownership of the console group devices to
the logged in user. A mechanism needs to be designed for assigning
ownership of secondary heads for the merged fb case. X should run as
the logged in user and not require root if the hardware allows.

21) It was also discussed the X should stop implementing OS level
features and instead use the features of the underlying OS. If the
underlying OS is lacking support the support would be implemented in a
library external to X. Examples of moving from X to OS support include:
PCI bus, input, console groupings, etc.

22) A goal this design is to discourage user space video driver
implementations when a kernel one exists. An example of this would be
X's radeon XAA driver. X would instead use the DRM driver via mesa.

23) The old schemes are not going to be removed. If your ancient 2D
card only has an fbdev and XAA driver it will still work. We're not
going to remove old drivers if new ones don't exist. But don't expect
the composting X server to turn your clunker 2D card in to a Radeon
X800.










=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: OLS and console rearchitecture

[Alexander E. Patrakov]

Jon Smirl wrote:
> 15) Over time user space console will be moved to a model where VT's
> are implemented in user space. This allows user space console access to
> fully accelerated drawing libraries. This might allow removal of all of
> the tty/vc layer code avoiding the need to fix it for SMP.

One more minor problem. We need to ensure somehow that the "killall5" 
program from the sysvinit package will not kill our userspace console 
daemon at shutdown (got this when I tried to put fbiterm into 
initramfs). What is the best way to achieve that?

-- 
Alexander E. Patrakov

Re: OLS and console rearchitecture

[Miquel van Smoorenburg]

In article <410E55AA.8030709@ums.usu.ru>,
Alexander E. Patrakov <patrakov@ums.usu.ru> wrote:
>Jon Smirl wrote:
>> 15) Over time user space console will be moved to a model where VT's
>> are implemented in user space. This allows user space console access to
>> fully accelerated drawing libraries. This might allow removal of all of
>> the tty/vc layer code avoiding the need to fix it for SMP.
>
>One more minor problem. We need to ensure somehow that the "killall5" 
>program from the sysvinit package will not kill our userspace console 
>daemon at shutdown (got this when I tried to put fbiterm into 
>initramfs). What is the best way to achieve that?

A configuration file for killall5 in which services/daemons get
defined that should not be signalled ?

Mike.
-- 
The question is, what is a "manamanap".
The question is, who cares ?

Re: OLS and console rearchitecture

[Andreas Schwab]

"Miquel van Smoorenburg" <miquels@cistron.nl> writes:

> In article <410E55AA.8030709@ums.usu.ru>,
> Alexander E. Patrakov <patrakov@ums.usu.ru> wrote:
>>Jon Smirl wrote:
>>> 15) Over time user space console will be moved to a model where VT's
>>> are implemented in user space. This allows user space console access to
>>> fully accelerated drawing libraries. This might allow removal of all of
>>> the tty/vc layer code avoiding the need to fix it for SMP.
>>
>>One more minor problem. We need to ensure somehow that the "killall5" 
>>program from the sysvinit package will not kill our userspace console 
>>daemon at shutdown (got this when I tried to put fbiterm into 
>>initramfs). What is the best way to achieve that?
>
> A configuration file for killall5 in which services/daemons get
> defined that should not be signalled ?

IMHO a better solution would be some kind of process flag that can be
interrogated by killall5.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: OLS and console rearchitecture

[Alan Cox]

On Llu, 2004-08-02 at 17:21, Andreas Schwab wrote:
> > A configuration file for killall5 in which services/daemons get
> > defined that should not be signalled ?
> 
> IMHO a better solution would be some kind of process flag that can be
> interrogated by killall5.

Policy belongs in user space. This is entirely policy and personal
preference.

Re: OLS and console rearchitecture

[Andreas Schwab]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Llu, 2004-08-02 at 17:21, Andreas Schwab wrote:
>> > A configuration file for killall5 in which services/daemons get
>> > defined that should not be signalled ?
>> 
>> IMHO a better solution would be some kind of process flag that can be
>> interrogated by killall5.
>
> Policy belongs in user space. This is entirely policy and personal
> preference.

The kernel would only function as a repository and makes sure the flag is
inherited across execve().  Any policy will only be set by user space.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: OLS and console rearchitecture

[Jon Smirl]

--- "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:
> Jon Smirl wrote:
> > 15) Over time user space console will be moved to a model where
> 
> One more minor problem. We need to ensure somehow that the "killall5"
> program from the sysvinit package will not kill our userspace console
> daemon at shutdown (got this when I tried to put fbiterm into 
> initramfs). What is the best way to achieve that?

When user space dies on shutdown output would switch over to the kernel
based console - the reverse process of what happens on start up. Do we
need more?

=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Re: OLS and console rearchitecture

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

hi :)

On Mon, Aug 02, 2004 at 09:16:56AM -0700, Jon Smirl wrote:
> When user space dies on shutdown output would switch over to the kernel
> based console - the reverse process of what happens on start up. Do we
> need more?

Yes, killall5 is not the last thing that runs in userspace.

Unmounting and stuff is done later and still has to be able to produce
visible output, so we still need our console daemon.

On bootup, console will be set up first, so there won't be any output
from userspace without the console daemon running

-- 
Martin Waitz

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OLS and console rearchitecture

[Jesse Barnes]

On Monday, August 2, 2004 7:24 am, Jon Smirl wrote:
> 1) PCI ROMs - these would be exposed via sysfs. A quirk is needed to
> track the boot video device and expose the contents of C000:0 for that
> special case. See the lkml thread: Exposing ROM's though sysfs, there
> are already proposed patches.

I just posted what I hope is a final patch for this one.  We'll see what 
gregkh comes back with.

> 2) VGA control - there needs to be a device for coordinating this. It
> would ensure that only a single VGA device gets enabled at a time. It
> would also adjust PCI bus routing as needed. It needs commands for
> disabling all VGA devices and then enabling a selected one. This device
> may need to coordinate with VGA console. You have to use this device
> even if you aren't using VGA console since it ensures that only a
> single VGA device gets enabled.
> Alan Cox: what about hardware that supports multiple vga routers? do we
> care?
> JS: no design work has been done for this device, what would be it's
> major/minor? would this be better done in sysfs?

It should probably be a real device driver rather than a sysfs pseudofile.  
Not sure if it should be dynamic or not though.  It would be nice if apps 
used the driver to do legacy VGA I/O port accesses as well, since that would 
make things easier on platforms that unconditionally master abort when a PIO 
times out, and would probably make it easier to deal with multiple domains.

Jesse

Re: OLS and console rearchitecture

[Benjamin Herrenschmidt]

> 
> It should probably be a real device driver rather than a sysfs pseudofile.  
> Not sure if it should be dynamic or not though.  It would be nice if apps 
> used the driver to do legacy VGA I/O port accesses as well, since that would 
> make things easier on platforms that unconditionally master abort when a PIO 
> times out, and would probably make it easier to deal with multiple domains.

I strongly agree. Also, access to VGA memory (in case that is necessary)
should be provided via MMAP on this driver too.

There are other reasons than master aborts to go that way, like platforms
that have multiple PCI domains with separate IO spaces that can accomodate
VGA cards in several of them.

Ben.

Re: OLS and console rearchitecture

[Helge Hafting]

Jon Smirl wrote:

>
>2) VGA control - there needs to be a device for coordinating this. It
>would ensure that only a single VGA device gets enabled at a time. It
>would also adjust PCI bus routing as needed. It needs commands for
>disabling all VGA devices and then enabling a selected one. This device
>may need to coordinate with VGA console. You have to use this device
>even if you aren't using VGA console since it ensures that only a
>single VGA device gets enabled.
>Alan Cox: what about hardware that supports multiple vga routers? do we
>care?
>  
>
Isn't the "unique VGA" a disappearing problem?
I have the impression that many new (PCI/AGP) video cards
can work fine without the legacy VGA stuff - therefore, no conflict
when using several cards simultaneously.

Please avoid unnecessary disabling of such devices, that only causes
trouble for those of use trying to use several screens at once. (Possibly
with several simultaneous _users_, who don't want their screen disabled 
for no
good reason.) Of course one may have to buy the "right" cards when 
setting up
such a machine.

Helge Hafting

Re: OLS and console rearchitecture

[Alan Cox]

On Iau, 2004-08-05 at 09:56, Helge Hafting wrote:
> Isn't the "unique VGA" a disappearing problem?

Alas not.

> Please avoid unnecessary disabling of such devices, that only causes
> trouble for those of use trying to use several screens at once. (Possibly
> with several simultaneous _users_, who don't want their screen disabled 
> for no
> good reason.) Of course one may have to buy the "right" cards when 
> setting up
> such a machine.

The goal is to have a control device to arbitrate it. This doesn't
generally cause a performance hit and X currently handles it internally
using RAC but once you have multiple uses of VGA space the arbitration
has to go kernel side