[PATCH 5/5] VT binding: Add new doc file describing the feature

[PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

This newly added file will:

- Describe the characteristics of 2 general types of console drivers
- How to use the sysfs to unbind and bind console drivers
- Uses for this feature

Signed-off-by: Antonino Daplas <adaplas@pol.net>
---

 Documentation/console/console.txt |  127 +++++++++++++++++++++++++++++++++++++
 1 files changed, 127 insertions(+), 0 deletions(-)

diff --git a/Documentation/console/console.txt b/Documentation/console/console.txt
new file mode 100644
index 0000000..4f3f285
--- /dev/null
+++ b/Documentation/console/console.txt
@@ -0,0 +1,127 @@
+Console Drivers
+===============
+
+The linux kernel has 2 general types of console drivers.  The first type is
+assigned by the kernel to all the virtual consoles during the boot process.
+This type will be called 'system driver', and only one system driver is allowed
+to exist. The system driver is persistent and it can never be unloaded, though
+it may become inactive.
+
+The second type has to be explicitly loaded and unloaded. This will be called
+'modular driver' by this document. Multiple modular drivers can coexist at
+any time with each driver sharing the console with other drivers including
+the system driver. However, modular drivers cannot take over the console
+that is currently occupied by another modular driver. (Exception: Drivers that
+call take_over_console() will succeed in the takeover regardless of the type
+of driver occupying the consoles.) They can only take over the console that is
+occupied by the system driver. In the same token, if the modular driver is
+released by the console, the system driver will take over.
+
+Modular drivers, from the programmer's point of view, has to call:
+
+	 take_over_console() - load and bind driver to console layer
+	 give_up_console() - unbind and unload driver
+
+In newer kernels, the following are also available:
+
+	 register_con_driver()
+	 unregister_con_driver()
+
+If sysfs is enabled, the contents of /sys/class/tty/console/backend can be
+examined. This shows the console drivers currently registered by the system. On
+an x86 system with the framebuffer console enabled, the contents of this
+attribute may be like this:
+
+cat /sys/class/tty/console/backend
+0 S: VGA+
+1 B: frame buffer device
+
+The first line shows the VGA console driver, while the second line shows
+the framebuffer console driver.
+
+The leftmost numeric character is the driver ID.  The middle character with
+the colon describes the status of the driver.
+
+    S: - system driver (binding unspecified)
+    B: - bound modular driver
+    U: - unbound modular driver
+
+The last column is the description of the driver.
+
+Under /sys/class/tty/console are two other attributes, 'bind' and
+'unbind'. What does these 2 attributes do? As their name implies, echo'ing the
+driver ID to 'bind' will bind an unbound modular driver, and to 'unbind' will
+unbind a bound modular driver. Echo'ing the ID of a system driver to either
+attribute will do nothing.
+
+Thus:
+
+echo 1 > /sys/class/tty/console/unbind
+cat /sys/class/tty/console/backend
+0 S: VGA+
+1 U: frame buffer device
+
+When unbinding, the modular driver is detached first, and then the system
+driver takes over the consoles vacated by the driver. Binding, on the other
+hand, will bind the driver to the consoles that are currently occupied by a
+system driver.
+
+How useful is this feature? This is very useful for console driver
+developers. By unbinding the driver from the console layer, one can unload the
+driver, make changes, recompile, reload and rebind the driver without any need
+for rebooting the kernel. For regular users who may want to switch from
+framebuffer console to VGA console and vice versa, this feature also makes
+this possible. (NOTE NOTE NOTE: Please read fbcon.txt under Documentation/fb
+for more details).
+
+Notes for developers:
+=====================
+
+take_over_console() is now broken up into:
+
+     register_con_driver()
+     bind_con_driver() - private function
+
+give_up_console() is a wrapper to unregister_con_driver(), and a driver must
+be fully unbound for this call to succeed. con_is_bound() will check if the
+driver is bound or not.
+
+Guidelines for console driver writers:
+=====================================
+
+In order for binding to and unbinding from the console to properly work,
+console drivers must follow these guidelines:
+
+1. All drivers, except system drivers, must call either register_con_driver()
+   or take_over_console(). register_con_driver() will just add the driver to
+   the console's internal list. It won't take over the
+   console. take_over_console(), as it name implies, will also take over (or
+   bind to) the console.
+
+2. All resources allocated during con->con_init() must be released in
+   con->con_deinit().
+
+3. All resources allocated in con->con_startup() must be released when the
+   driver, which was previously bound, becomes unbound.  The console layer
+   does not have a complementary call to con->con_startup() so it's up to the
+   driver to check when it's legal to release these resources. Calling
+   con_is_bound() in con->con_deinit() will help.  If the call returned
+   false(), then it's safe to release the resources.  This balance has to be
+   ensured because con->con_startup() can be called again when a request to
+   rebind the driver to the console arrives.
+
+4. Upon exit of the driver, ensure that the driver is totally unbound. If the
+   condition is satisfied, then the driver must call unregister_con_driver()
+   or give_up_console().
+
+5. unregister_con_driver() can also be called on conditions which make it
+   impossible for the driver to service console requests.  This can happen
+   with the framebuffer console that suddenly lost all of its drivers.
+
+The current crop of console drivers should still work correctly, but binding
+and unbinding them may cause problems. With minimal fixes, these drivers can
+be made to work correctly.
+
+==========================
+Antonino Daplas <adaplas@pol.net>
+

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/9/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> - Describe the characteristics of 2 general types of console drivers
> - How to use the sysfs to unbind and bind console drivers
> - Uses for this feature

I like this new binding feature and that for doing the work to make it
happen. It is definitely something I will use in the future.

From the docs I see a distinction between system consoles and modular
consoles, can't all consoles be created equally? The only rule would
be, that if there is only a single console registered it can't be
unbound or unregistered. It shouldn't matter which console is the last
one left.

We have these console systems: dummy, serial, vga, mda, prom, sti,
newport, sisusb, fb, network (isn't there some way to use the net for
console?)

All of these console system could follow the same protocol for
registering/binding as the modular consoles so we would end up with a
single class of console, not modular vs system.
Of course some of these consoles are built in and are never going to
unregister themselves, but that doesn't meant that their binding
sequence has to be different from the modular systems.

For example I can easily see VGA being converted from built-in to
modular. There have also been times when I was working on video
drivers that I wanted to switch to a serial console. For symmetry
dummycon should be built into all systems.

As for the way the sysfs attribute works, in a similar situation in fb
I used two attributes. Maybe 'backends' which is a read only list of
available console systems. And 'backend' which is read/write. Copy one
of the names from 'backends' to 'backend' to swtich the active/bound
console. Cat 'backend' to see the active console. Any idea on a better
name than 'backend'?

cat /sys/class/tty/console/backends
vga
serial
dummy
fb

cat /sys/class/tty/console/backend
vga

echo fb >/sys/class/tty/console/backend

cat /sys/class/tty/console/backend
fb

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/9/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> - Describe the characteristics of 2 general types of console drivers
>> - How to use the sysfs to unbind and bind console drivers
>> - Uses for this feature
> 
> I like this new binding feature and that for doing the work to make it
> happen. It is definitely something I will use in the future.
> 
>> From the docs I see a distinction between system consoles and modular
> consoles, can't all consoles be created equally?  The only rule would
> be, that if there is only a single console registered it can't be
> unbound or unregistered. It shouldn't matter which console is the last
> one left.

Yes, it can be made that way. I just made it like that because
system consoles, since they are initialized very, very early, have to
be compiled statically. Therefore, they have can never be unloaded. So
why give them the prerogative to directly unbind, when they can never
be unloaded? One can unbind them anyway by binding a modular driver.

It would also make binding/unbinding a more complicated process.

> 
> We have these console systems: dummy, serial, vga, mda, prom, sti,
> newport, sisusb, fb, network (isn't there some way to use the net for
> console?)

network is different.  It's a different class of console itself.  We
have different console classes BTW. We have netconsole, serial console,
vt consoles etc. fbcon, vgacon, promcon, etc all fall under the vt
console class.

> 
> All of these console system could follow the same protocol for
> registering/binding as the modular consoles so we would end up with a
> single class of console, not modular vs system.

That was the plan before, the problem here is that we won't have any
output during the early part of the boot process. That's why I
differentiated them into system and modular consoles.

> Of course some of these consoles are built in and are never going to
> unregister themselves, but that doesn't meant that their binding
> sequence has to be different from the modular systems.
> 
> For example I can easily see VGA being converted from built-in to
> modular. There have also been times when I was working on video
> drivers that I wanted to switch to a serial console. For symmetry
> dummycon should be built into all systems.

As mentioned above, making vgacon (and other system drivers) take this
pathway means we lose output during the early part.  

> 
> As for the way the sysfs attribute works, in a similar situation in fb
> I used two attributes. Maybe 'backends' which is a read only list of
> available console systems. And 'backend' which is read/write. Copy one
> of the names from 'backends' to 'backend' to swtich the active/bound
> console. Cat 'backend' to see the active console. Any idea on a better
> name than 'backend'?
> 
> cat /sys/class/tty/console/backends
> vga
> serial
> dummy
> fb
> 
> cat /sys/class/tty/console/backend
> vga
> 
> echo fb >/sys/class/tty/console/backend
> 
> cat /sys/class/tty/console/backend
> fb
> 

I was thinking of changing it to something like this, after GregKH's
suggestion:

/sys/class/vtconsole --- vgacon - bind
                     : 
                     --- fbcon - bind
                     : 
                     --- dummycon - bind

... with the 'bind' as a r/w attribute, 0 for unbound/unbind, 1 for
bound/bind. 

What do you think?

Tony

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Jon Smirl wrote:
> > On 6/9/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> - Describe the characteristics of 2 general types of console drivers
> >> - How to use the sysfs to unbind and bind console drivers
> >> - Uses for this feature
> >
> > I like this new binding feature and that for doing the work to make it
> > happen. It is definitely something I will use in the future.
> >
> >> From the docs I see a distinction between system consoles and modular
> > consoles, can't all consoles be created equally?  The only rule would
> > be, that if there is only a single console registered it can't be
> > unbound or unregistered. It shouldn't matter which console is the last
> > one left.
>
> Yes, it can be made that way. I just made it like that because
> system consoles, since they are initialized very, very early, have to
> be compiled statically. Therefore, they have can never be unloaded. So
> why give them the prerogative to directly unbind, when they can never
> be unloaded? One can unbind them anyway by binding a modular driver.
>
> It would also make binding/unbinding a more complicated process.

I may be looking at the problem a little differently. I see the
drivers like fb, vga, etc as registering with the console and saying
they are capable of providing console services. I then see the console
system as opening one of the registered devices. A driver is free to
register/unregister whenever it wants to as long as it isn't open by
the console system. Console can only open one driver at a time.
Opening another driver automatically closes the previous driver and
one driver always has to be open.

> I was thinking of changing it to something like this, after GregKH's
> suggestion:
>
> /sys/class/vtconsole --- vgacon - bind
>                      :
>                      --- fbcon - bind
>                      :
>                      --- dummycon - bind
>
> ... with the 'bind' as a r/w attribute, 0 for unbound/unbind, 1 for
> bound/bind.

This model implies that more than one driver can be open which isn't
true.  Since there is one attribute per driver this also implies that
binding(registering) is a driver attribute, not a console one.

If you move binding(registering) over to be a driver property it
doesn't need to be an explicit attribute. When a driver first loads it
will always register with console. When it unloads it will always
unregister and we know that the unregister will succeed because if
console has you open you won't be able to unload and get to the
unregister code.

The problem with the previous system was that bind(register) and open
were combined into a single operation when they should be separate. I
should be able to load four console drivers and then pick the one I
want to switch to without automatically having the console jump to
each device as the drivers are loaded.

> > We have these console systems: dummy, serial, vga, mda, prom, sti,
> > newport, sisusb, fb, network (isn't there some way to use the net for
> > console?)
>
> network is different.  It's a different class of console itself.  We
> have different console classes BTW. We have netconsole, serial console,
> vt consoles etc. fbcon, vgacon, promcon, etc all fall under the vt
> console class.

Over time it would nice if these all merged to a single
interchangeable interface. I would really like to be able to
dynamically switch to serial/net while debugging a video driver. Is
there some fundamental reason why these can't be merged?

> > All of these console system could follow the same protocol for
> > registering/binding as the modular consoles so we would end up with a
> > single class of console, not modular vs system.
>
> That was the plan before, the problem here is that we won't have any
> output during the early part of the boot process. That's why I
> differentiated them into system and modular consoles.

The current way of doing this still works. If a console driver is
compiled in use the CONFIG flags to statically initialize it's
registration(bind) state with console. Console will then just open the
first one it finds. Registering just says, here's a pointer I'm able
to be a console. Unregistering takes the pointer away. I agree that
there has to be a protocol exception in this case since the console
drivers don't get initialized until after we want console output.

> What do you think?

Am I making more sense now?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> The problem with the previous system was that bind(register) and open
> were combined into a single operation when they should be separate. I
> should be able to load four console drivers and then pick the one I
> want to switch to without automatically having the console jump to
> each device as the drivers are loaded.

I should clarify this, take_over_console() combines the registration
and open operations. If I loaded four console drivers using
take_over_console() my console would bounce from device to device as
the drivers are loaded. The real problem with the take_over_console()
implementation was that it effectively made loading console drivers
into a stack operation instead of a set operation.

take_over_console() is not incompatible with the scheme I described in
the previous mail if the implementation is changed inside console.
The new implementation would just call the register and open
operations as described earlier. When loading four consoles using
take_over_console() you would still bounce through the four consoles
but once loaded the console drivers would act as a set. You could use
sysfs to switch to any of the registered consoles. If a console driver
is not open it could be unloaded in any order.

Long term I think take_over_console() should be deprecated in favor of
a register(bind) call from the console driver and an explicit sysfs
action to move the console.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> I may be looking at the problem a little differently. I see the
> drivers like fb, vga, etc as registering with the console and saying
> they are capable of providing console services. I then see the console
> system as opening one of the registered devices. A driver is free to
> register/unregister whenever it wants to as long as it isn't open by
> the console system. Console can only open one driver at a time.
> Opening another driver automatically closes the previous driver and
> one driver always has to be open.

An example might help clarify this.

Imagine that you have three console drivers (vga, serial, fb) and one
console system all implemented as modules. I'm not saying make console
a module, just pretend like it is one.

First you would modprobe in the console system.
Next modprobe in the three console drivers which automatically
register with the console system.

At this point the console system would have a ref count of 3. It can
not be unloaded until the three console drivers have unregistered.

Now console opens the vga console driver, that will increment the ref
count on that driver.

Now switch to the serial driver, ref count will go to zero on vga and
one one serial.

At this point vga and fb could be unloaded if they were modules.

If console contains the rule that it always has to keep a console
open, it will be bound into memory since it will never be possible to
get its ref count to zero.

In the old model take_over_console() effectively combined these refs
counts so that it was impossible to unload anything once it was
loaded. There was no mechanism to decrement the ref count on the
console drivers.


-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Jon Smirl wrote:
>> > On 6/9/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> >> - Describe the characteristics of 2 general types of console drivers
>> >> - How to use the sysfs to unbind and bind console drivers
>> >> - Uses for this feature
>> >
>> > I like this new binding feature and that for doing the work to make it
>> > happen. It is definitely something I will use in the future.
>> >
>> >> From the docs I see a distinction between system consoles and modular
>> > consoles, can't all consoles be created equally?  The only rule would
>> > be, that if there is only a single console registered it can't be
>> > unbound or unregistered. It shouldn't matter which console is the last
>> > one left.
>>
>> Yes, it can be made that way. I just made it like that because
>> system consoles, since they are initialized very, very early, have to
>> be compiled statically. Therefore, they have can never be unloaded. So
>> why give them the prerogative to directly unbind, when they can never
>> be unloaded? One can unbind them anyway by binding a modular driver.
>>
>> It would also make binding/unbinding a more complicated process.
> 
> I may be looking at the problem a little differently. I see the
> drivers like fb, vga, etc as registering with the console and saying
> they are capable of providing console services. I then see the console
> system as opening one of the registered devices. A driver is free to
> register/unregister whenever it wants to as long as it isn't open by
> the console system. Console can only open one driver at a time.

No, this isn't true.  You can have multiple console drivers active,
that's why you have a first and last parameter in take_over_console().
Thus at boot time, the system driver will take consoles 0 - 63.
Later on when a driver loads, it can take over consoles 0 - 7, leaving
consoles 8 - 63 to the system driver.

To put it another way, console drivers can register for consoles 0 - 63,
but the user may choose to use it only for consoles 0 - 7.

This is another reason for the system driver, it makes the unbinding
behavior predictable.  Without a system driver, guessing which driver
replaces the just unbound one may become just a tad bit confusing for
the typical user.

> Opening another driver automatically closes the previous driver and
> one driver always has to be open.
> 
>> I was thinking of changing it to something like this, after GregKH's
>> suggestion:
>>
>> /sys/class/vtconsole --- vgacon - bind
>>                      :
>>                      --- fbcon - bind
>>                      :
>>                      --- dummycon - bind
>>

Just tried the above, but it's a mouthful, as the name is based
on the description. So I already changed it to this:

/sys/class/vtconsole --- vtcon0
                      :
                     --- vtcon1

Each class device file has 2 attributes:

bind - r/w attribute
name - description of the current backend

>> ... with the 'bind' as a r/w attribute, 0 for unbound/unbind, 1 for
>> bound/bind.
> 
> This model implies that more than one driver can be open which isn't
> true.

Yes it implies that and no, it is true. So that is a model compatible
with the current implementation. What's lacking still is fine-grained
control, ie, for the user to bind/unbind only a specific range of
consoles. It's possible to add this fine-grained control in:

/sys/class/tty/tty[n] 

...but that will be for the future.

> Since there is one attribute per driver this also implies that
> binding(registering) is a driver attribute, not a console one.

The revised model should fix this.

> 
> If you move binding(registering) over to be a driver property it
> doesn't need to be an explicit attribute. When a driver first loads it
> will always register with console. When it unloads it will always
> unregister and we know that the unregister will succeed because if
> console has you open you won't be able to unload and get to the
> unregister code.
> 
> The problem with the previous system was that bind(register) and open
> were combined into a single operation when they should be separate. I
> should be able to load four console drivers and then pick the one I
> want to switch to without automatically having the console jump to
> each device as the drivers are loaded.
> 
>> > We have these console systems: dummy, serial, vga, mda, prom, sti,
>> > newport, sisusb, fb, network (isn't there some way to use the net for
>> > console?)
>>
>> network is different.  It's a different class of console itself.  We
>> have different console classes BTW. We have netconsole, serial console,
>> vt consoles etc. fbcon, vgacon, promcon, etc all fall under the vt
>> console class.
> 
> Over time it would nice if these all merged to a single
> interchangeable interface. I would really like to be able to
> dynamically switch to serial/net while debugging a video driver. Is
> there some fundamental reason why these can't be merged?

It's already possible to redirect the system messages to two different
console classes, ie with the boot parameter:

console=tty0,ttyS0 /* direct output to VT and serial console */

And you can already choose the console you want by adjusting /etc/inittab.

Tony

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > I may be looking at the problem a little differently. I see the
> > drivers like fb, vga, etc as registering with the console and saying
> > they are capable of providing console services. I then see the console
> > system as opening one of the registered devices. A driver is free to
> > register/unregister whenever it wants to as long as it isn't open by
> > the console system. Console can only open one driver at a time.
>
> No, this isn't true.  You can have multiple console drivers active,
> that's why you have a first and last parameter in take_over_console().
> Thus at boot time, the system driver will take consoles 0 - 63.
> Later on when a driver loads, it can take over consoles 0 - 7, leaving
> consoles 8 - 63 to the system driver.
>
> To put it another way, console drivers can register for consoles 0 - 63,
> but the user may choose to use it only for consoles 0 - 7.
>
> This is another reason for the system driver, it makes the unbinding
> behavior predictable.  Without a system driver, guessing which driver
> replaces the just unbound one may become just a tad bit confusing for
> the typical user.

I find the whole console/tty layer to be quite confusing to talk
about. I am mixing up console as in where printk goes and console the
video card login device. The part about making everything equal was
directed towards the printk output device.

I see now that you can have tty0-7 assigned to a different console
driver than tty8-63.
Why do I want to do this?
Why do we need 64 predefined tty devices?

Googling around the only example I could find was someone with a VGA
card and a Hercules card. They setup 8 consoles on each card.

> > Over time it would nice if these all merged to a single
> > interchangeable interface. I would really like to be able to
> > dynamically switch to serial/net while debugging a video driver. Is
> > there some fundamental reason why these can't be merged?
>
> It's already possible to redirect the system messages to two different
> console classes, ie with the boot parameter:
>
> console=tty0,ttyS0 /* direct output to VT and serial console */
>
> And you can already choose the console you want by adjusting /etc/inittab.

How can I change where printk are going at run-time? I didn't know you
could do that.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> > I may be looking at the problem a little differently. I see the
>> > drivers like fb, vga, etc as registering with the console and saying
>> > they are capable of providing console services. I then see the console
>> > system as opening one of the registered devices. A driver is free to
>> > register/unregister whenever it wants to as long as it isn't open by
>> > the console system. Console can only open one driver at a time.
>>
>> No, this isn't true.  You can have multiple console drivers active,
>> that's why you have a first and last parameter in take_over_console().
>> Thus at boot time, the system driver will take consoles 0 - 63.
>> Later on when a driver loads, it can take over consoles 0 - 7, leaving
>> consoles 8 - 63 to the system driver.
>>
>> To put it another way, console drivers can register for consoles 0 - 63,
>> but the user may choose to use it only for consoles 0 - 7.
>>
>> This is another reason for the system driver, it makes the unbinding
>> behavior predictable.  Without a system driver, guessing which driver
>> replaces the just unbound one may become just a tad bit confusing for
>> the typical user.
> 
> I find the whole console/tty layer to be quite confusing to talk
> about. I am mixing up console as in where printk goes and console the
> video card login device. The part about making everything equal was
> directed towards the printk output device.
> 

Sorry about that, I probably should use VT or VC for the main topic
of this thread, and plain 'console' for where the printk output goes.

This illustration might help, though I'm not sure if it's entirely
correct. The main topic of this thread deals with the VT branch only.

Console
   :
   :-----:-----------:--- etc
   :     :           :
   VT    Serial      Net
   :
   :--------:-------:-----etc
   :        :       : 
   vgacon   fbcon   newport_con
   :        :       :
   :        :       :
   hardware fbdev   hardware
            :
            :
            hardware


> I see now that you can have tty0-7 assigned to a different console
> driver than tty8-63.
> Why do I want to do this?

Multi-head.  I can have vgacon on the primary card for tty0-7,
fbcon on the secondary card for tty8-16.

> Why do we need 64 predefined tty devices?

I don't know, but no one's stopping you to redefine MAX_NR_CONSOLES to
a lower or higher number.

> 
> Googling around the only example I could find was someone with a VGA
> card and a Hercules card. They setup 8 consoles on each card.
> 
>> > Over time it would nice if these all merged to a single
>> > interchangeable interface. I would really like to be able to
>> > dynamically switch to serial/net while debugging a video driver. Is
>> > there some fundamental reason why these can't be merged?
>>
>> It's already possible to redirect the system messages to two different
>> console classes, ie with the boot parameter:
>>
>> console=tty0,ttyS0 /* direct output to VT and serial console */
>>
>> And you can already choose the console you want by adjusting
>> /etc/inittab.
> 
> How can I change where printk are going at run-time? I didn't know you
> could do that.

I really don't know.  Maybe we have some kind of entry in /proc somewhere?

Tony

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > I see now that you can have tty0-7 assigned to a different console
> > driver than tty8-63.
> > Why do I want to do this?
>
> Multi-head.  I can have vgacon on the primary card for tty0-7,
> fbcon on the secondary card for tty8-16.

That's what I thought, I couldn't see any other reason. The kernel
doesn't support input from multiple users so multihead can only be
used by a single user.

Does anyone use single user multihead on current systems? The kernel
doesn't have code in it to initialize secondary VGA cards. What modern
non-VGA hardware does this work on?

If this feature doesn't work on current hardware, could it be dropped?
It would make binding to the vt system much simpler if only one driver
could be bound at a time. Anything we do to make that system simpler
would benefit everyone.

At some future point I would like to explore pushing the VT system out
to user space where it becomes much easier to make it multi-user and
multi-head. If you do that, something like a single user, in-kernel
system management console makes more sense.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > > I see now that you can have tty0-7 assigned to a different console
> > > driver than tty8-63.
> > > Why do I want to do this?
> >
> > Multi-head.  I can have vgacon on the primary card for tty0-7,
> > fbcon on the secondary card for tty8-16.
>
> That's what I thought, I couldn't see any other reason. The kernel
> doesn't support input from multiple users so multihead can only be
> used by a single user.
>
> Does anyone use single user multihead on current systems? The kernel
> doesn't have code in it to initialize secondary VGA cards. What modern
> non-VGA hardware does this work on?

The kernel is also missing the logic for controlling which VGA card is
active when multiple ones exist in the same box.

> If this feature doesn't work on current hardware, could it be dropped?
> It would make binding to the vt system much simpler if only one driver
> could be bound at a time. Anything we do to make that system simpler
> would benefit everyone.

When I say dropped, I mean drop the feature of having multiple drivers
simultaneously open by the VT layer. You would still be able to switch
from vgacon to fbcon by using sysfs. You just wouldn't be able to use
VT swap hotkeys between them.

> At some future point I would like to explore pushing the VT system out
> to user space where it becomes much easier to make it multi-user and
> multi-head. If you do that, something like a single user, in-kernel
> system management console makes more sense.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> > > I see now that you can have tty0-7 assigned to a different console
>> > > driver than tty8-63.
>> > > Why do I want to do this?
>> >
>> > Multi-head.  I can have vgacon on the primary card for tty0-7,
>> > fbcon on the secondary card for tty8-16.
>>
> 
> When I say dropped, I mean drop the feature of having multiple drivers
> simultaneously open by the VT layer. You would still be able to switch
> from vgacon to fbcon by using sysfs. You just wouldn't be able to use
> VT swap hotkeys between them.

Quoting you:

"Googling around the only example I could find was someone with a VGA
card and a Hercules card. They setup 8 consoles on each card."

How do you think they accomplished that? They did not rewrite the VT
layer, all they need to do is change the 'first' and 'last' parameter
passed to take_over_console() in mdacon.c.  This implies that the VT
layer already supports multiple active VT console drivers, maybe as
early as 2.2, and no, we won't remove that.

Tony 

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Jon Smirl wrote:
> > On 6/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> > > I see now that you can have tty0-7 assigned to a different console
> >> > > driver than tty8-63.
> >> > > Why do I want to do this?
> >> >
> >> > Multi-head.  I can have vgacon on the primary card for tty0-7,
> >> > fbcon on the secondary card for tty8-16.
> >>
> >
> > When I say dropped, I mean drop the feature of having multiple drivers
> > simultaneously open by the VT layer. You would still be able to switch
> > from vgacon to fbcon by using sysfs. You just wouldn't be able to use
> > VT swap hotkeys between them.
>
> Quoting you:
>
> "Googling around the only example I could find was someone with a VGA
> card and a Hercules card. They setup 8 consoles on each card."
>
> How do you think they accomplished that? They did not rewrite the VT
> layer, all they need to do is change the 'first' and 'last' parameter
> passed to take_over_console() in mdacon.c.  This implies that the VT
> layer already supports multiple active VT console drivers, maybe as
> early as 2.2, and no, we won't remove that.

But the hardware has changed. The kernel is missing a lot of the
support needed for multiple VGA cards in a single box so that option
isn't legal. So this needs to be done with non-VGA cards. Are there
non-VGA cards still in production where a user would want to put
multiple cards in their box? As far as I know they aren't any in the
x86 world, I don't know about other architectures.

All modern Hercules cards are VGA based, they use NVidia and ATI
chips. The reference was from 1998, they were referring to the ancient
Hercules cards that were non-VGA.

Back in the days of CGA, MDA, HGC, 8514, etc this situation was
common, but now everything is VGA.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Jon Smirl wrote:
>> > On 6/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:
>> >> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> >> > > I see now that you can have tty0-7 assigned to a different console
>> >> > > driver than tty8-63.
>> >> > > Why do I want to do this?
>> >> >
>> >> > Multi-head.  I can have vgacon on the primary card for tty0-7,
>> >> > fbcon on the secondary card for tty8-16.
>> >>
>> >
>> > When I say dropped, I mean drop the feature of having multiple drivers
>> > simultaneously open by the VT layer. You would still be able to switch
>> > from vgacon to fbcon by using sysfs. You just wouldn't be able to use
>> > VT swap hotkeys between them.
>>
>> Quoting you:
>>
>> "Googling around the only example I could find was someone with a VGA
>> card and a Hercules card. They setup 8 consoles on each card."
>>
>> How do you think they accomplished that? They did not rewrite the VT
>> layer, all they need to do is change the 'first' and 'last' parameter
>> passed to take_over_console() in mdacon.c.  This implies that the VT
>> layer already supports multiple active VT console drivers, maybe as
>> early as 2.2, and no, we won't remove that.
> 
> But the hardware has changed. The kernel is missing a lot of the
> support needed for multiple VGA cards in a single box so that option
> isn't legal. So this needs to be done with non-VGA cards. Are there
> non-VGA cards still in production where a user would want to put
> multiple cards in their box? As far as I know they aren't any in the
> x86 world, I don't know about other architectures.
> 
> All modern Hercules cards are VGA based, they use NVidia and ATI
> chips. The reference was from 1998, they were referring to the ancient
> Hercules cards that were non-VGA.
> 
> Back in the days of CGA, MDA, HGC, 8514, etc this situation was
> common, but now everything is VGA.
> 

It doesn't really matter what the hardware is.  We have a feature that
is supported in the kernel for a long time, we can't just drop it
because we do not have the capability to initialize secondary cards?
That's too x86-centric.

And even today, in an x86 system, we can support multiple vt drivers
in one system:

primary card - vgacon
secondary card - fbcon (the secondary card initialized by X perhaps,
	or even any tool that uses lrmi).

But the argument is moot anyway.  Users won't be able to support
multiple drivers at one time without hacking the kernel. We are not
giving them the interface nor the control to do that, except perhaps
for fbcon, but that option was present for a long time.  

Tony

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Geert Uytterhoeven]

On Sun, 11 Jun 2006, Antonino A. Daplas wrote:
> Jon Smirl wrote:
> > On 6/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> > > I see now that you can have tty0-7 assigned to a different console
> >> > > driver than tty8-63.
> >> > > Why do I want to do this?
> >> >
> >> > Multi-head.  I can have vgacon on the primary card for tty0-7,
> >> > fbcon on the secondary card for tty8-16.
> >>
> > 
> > When I say dropped, I mean drop the feature of having multiple drivers
> > simultaneously open by the VT layer. You would still be able to switch
> > from vgacon to fbcon by using sysfs. You just wouldn't be able to use
> > VT swap hotkeys between them.
> 
> Quoting you:
> 
> "Googling around the only example I could find was someone with a VGA
> card and a Hercules card. They setup 8 consoles on each card."
> 
> How do you think they accomplished that? They did not rewrite the VT
> layer, all they need to do is change the 'first' and 'last' parameter
> passed to take_over_console() in mdacon.c.  This implies that the VT
> layer already supports multiple active VT console drivers, maybe as
> early as 2.2, and no, we won't remove that.

JFYI, probably 2.1.x. Multi-head dates back to at least 1996.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> > I see now that you can have tty0-7 assigned to a different console
>> > driver than tty8-63.
>> > Why do I want to do this?
>>
>> Multi-head.  I can have vgacon on the primary card for tty0-7,
>> fbcon on the secondary card for tty8-16.
> 
> That's what I thought, I couldn't see any other reason. The kernel
> doesn't support input from multiple users so multihead can only be
> used by a single user.
> 
> Does anyone use single user multihead on current systems? The kernel
> doesn't have code in it to initialize secondary VGA cards. What modern
> non-VGA hardware does this work on?

matroxfb supports multihead and fbcon already has this feature for a
long time, ie you can bind /dev/fb0 to tty0-3 and /dev/fb1 to tty4-6.
And there are definite users because I happen to break this feature once
and I got rained with complaints :-)

> 
> If this feature doesn't work on current hardware, could it be dropped?
> It would make binding to the vt system much simpler if only one driver
> could be bound at a time. Anything we do to make that system simpler
> would benefit everyone.

You can't drop something that's already in the kernel and has users, well,
the binding part at least. What we don't currently have is the fine-grained
control and because of the reason's you mentioned, I said that it's for the
future.

(Note1: fbcon already has support to selectively bind/unbind drivers
to specific tty's, using the con2fbmap utility.)

So what we have is control for wholescale binding and unbinding of
drivers, which essentially results in only 1 driver loaded at one time.

(Note2: fbcon already has an option to determine what range of vc's to
control, as a kernel boot parameter, so we can't just drop something 
that's already supported by one driver at least.  Though I know of no one,
including myself, who uses this feature.)

> 
> At some future point I would like to explore pushing the VT system out
> to user space where it becomes much easier to make it multi-user and
> multi-head. If you do that, something like a single user, in-kernel
> system management console makes more sense.

Yes.

Tony

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Jon Smirl wrote:
> > On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> > I see now that you can have tty0-7 assigned to a different console
> >> > driver than tty8-63.
> >> > Why do I want to do this?
> >>
> >> Multi-head.  I can have vgacon on the primary card for tty0-7,
> >> fbcon on the secondary card for tty8-16.
> >
> > That's what I thought, I couldn't see any other reason. The kernel
> > doesn't support input from multiple users so multihead can only be
> > used by a single user.
> >
> > Does anyone use single user multihead on current systems? The kernel
> > doesn't have code in it to initialize secondary VGA cards. What modern
> > non-VGA hardware does this work on?
>
> matroxfb supports multihead and fbcon already has this feature for a
> long time, ie you can bind /dev/fb0 to tty0-3 and /dev/fb1 to tty4-6.
> And there are definite users because I happen to break this feature once
> and I got rained with complaints :-)

Were those people using this: http://linuxconsole.sourceforge.net/
Does that work anymore?

This is single a single driver bound to the vt layer. Support for both
fb0 and fb1 are provided by that single driver. So there may be some
way to make this work.

> > If this feature doesn't work on current hardware, could it be dropped?
> > It would make binding to the vt system much simpler if only one driver
> > could be bound at a time. Anything we do to make that system simpler
> > would benefit everyone.
>
> You can't drop something that's already in the kernel and has users, well,
> the binding part at least. What we don't currently have is the fine-grained
> control and because of the reason's you mentioned, I said that it's for the
> future.

There are variations on 'drop' is it dropping if we provide an
alternate way to achieve the same thing?

Does matroxfb know which VC number it is drawing too? If so, we could
move the mapping between head and VC down to an attribute on the
matroxfb driver. That would allow the general case of the VC layer
binding to be simplified to opening a single driver.

That is not an attribute you want long term on the matroxfb driver,
but all of this would get more cleanly sorted out when a user space
implementation happens.

> (Note1: fbcon already has support to selectively bind/unbind drivers
> to specific tty's, using the con2fbmap utility.)

Could a variation on this be used to bind the matrox heads to a
specific tty? Is that binding happening inside fbcon or the vt layer?

>
> So what we have is control for wholescale binding and unbinding of
> drivers, which essentially results in only 1 driver loaded at one time.
>
> (Note2: fbcon already has an option to determine what range of vc's to
> control, as a kernel boot parameter, so we can't just drop something
> that's already supported by one driver at least.  Though I know of no one,
> including myself, who uses this feature.)
>
> >
> > At some future point I would like to explore pushing the VT system out
> > to user space where it becomes much easier to make it multi-user and
> > multi-head. If you do that, something like a single user, in-kernel
> > system management console makes more sense.
>
> Yes.
>
> Tony
>
>
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Jon Smirl wrote:
>> > On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> >> > I see now that you can have tty0-7 assigned to a different console
>> >> > driver than tty8-63.
>> >> > Why do I want to do this?
>> >>
>> >> Multi-head.  I can have vgacon on the primary card for tty0-7,
>> >> fbcon on the secondary card for tty8-16.
>> >
>> > That's what I thought, I couldn't see any other reason. The kernel
>> > doesn't support input from multiple users so multihead can only be
>> > used by a single user.
>> >
>> > Does anyone use single user multihead on current systems? The kernel
>> > doesn't have code in it to initialize secondary VGA cards. What modern
>> > non-VGA hardware does this work on?
>>
>> matroxfb supports multihead and fbcon already has this feature for a
>> long time, ie you can bind /dev/fb0 to tty0-3 and /dev/fb1 to tty4-6.
>> And there are definite users because I happen to break this feature once
>> and I got rained with complaints :-)
> 
> Were those people using this: http://linuxconsole.sourceforge.net/
> Does that work anymore?

No, plain vanilla kernel support this feature. There are lots of
users using the single-user, multi-head feature of fbcon. I've been using it.
The developer of one of the cyber cards also use it.

The main goal of the linuxconsole people is true multiuser, multihead.
One user per card simultaneously.

> 
> This is single a single driver bound to the vt layer. Support for both
> fb0 and fb1 are provided by that single driver. So there may be some
> way to make this work.
> 

Yes, fbcon does intermediate between drivers, so it's not a problem.

>> > If this feature doesn't work on current hardware, could it be dropped?
>> > It would make binding to the vt system much simpler if only one driver
>> > could be bound at a time. Anything we do to make that system simpler
>> > would benefit everyone.
>>
>> You can't drop something that's already in the kernel and has users,
>> well,
>> the binding part at least. What we don't currently have is the
>> fine-grained
>> control and because of the reason's you mentioned, I said that it's
>> for the
>> future.
> 
> There are variations on 'drop' is it dropping if we provide an
> alternate way to achieve the same thing?

Yes, by not providing the user with the option to load and bind
multiple drivers at one time, we are essentially not supporting this
feature.  And that's not a problem. /sys/class/vtconsole/vtcon[x]/bind
handles wholesale binding and unbinding, ie, when you echo 1 > bind,
only that driver, and nothing else, becomes active.

My point is: 'Multiple active drivers feature' is a natural consequence
of the evolution of the code, but the only way to take advantage of it
is if we provide a means for the user to use it.  And we are not
providing the means.

> 
> Does matroxfb know which VC number it is drawing too? If so, we could
> move the mapping between head and VC down to an attribute on the
> matroxfb driver. That would allow the general case of the VC layer
> binding to be simplified to opening a single driver.
> 
> That is not an attribute you want long term on the matroxfb driver,
> but all of this would get more cleanly sorted out when a user space
> implementation happens.

No, matroxfb and any other fbdev drivers has no knowledge whatsoever about
the console.

Tony

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> My point is: 'Multiple active drivers feature' is a natural consequence
> of the evolution of the code, but the only way to take advantage of it
> is if we provide a means for the user to use it.  And we are not
> providing the means.

I'd rather not provide the means and defer this capability to a user
space implementation where we can achieve true multi-user,
multi-adapter and multi-head support. The more features we add to the
VT layer today, the harder it will be to replace it in the future.

I'd like to keep the sysfs attributes as simple as possible because if
they get too complex and flexible no one is going to know how to set
them. But you're writing the code and you'll do what you think is
best.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> My point is: 'Multiple active drivers feature' is a natural consequence
>> of the evolution of the code, but the only way to take advantage of it
>> is if we provide a means for the user to use it.  And we are not
>> providing the means.
> 
> I'd rather not provide the means and defer this capability to a user
> space implementation where we can achieve true multi-user,
> multi-adapter and multi-head support. The more features we add to the
> VT layer today, the harder it will be to replace it in the future.

No, I'm not adding any new features.  We have bind capability, the only
added feature is unbind, that's it.

> 
> I'd like to keep the sysfs attributes as simple as possible because if
> they get too complex and flexible no one is going to know how to set
> them. But you're writing the code and you'll do what you think is
> best.

I'm just trying to evolve the code, with the least amount or no breakage.
There's nothing revolutionary here.

Tony

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> My point is: 'Multiple active drivers feature' is a natural consequence
>> of the evolution of the code, but the only way to take advantage of it
>> is if we provide a means for the user to use it.  And we are not
>> providing the means.

Maybe you're misunderstanding me. When I say "we are not providing the
means", I mean "we are definitely not going to provide the means", NOT,
"so we should be providing the means".

Tony

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Jon Smirl]

On 6/11/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Jon Smirl wrote:
> > On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> My point is: 'Multiple active drivers feature' is a natural consequence
> >> of the evolution of the code, but the only way to take advantage of it
> >> is if we provide a means for the user to use it.  And we are not
> >> providing the means.
>
> Maybe you're misunderstanding me. When I say "we are not providing the
> means", I mean "we are definitely not going to provide the means", NOT,
> "so we should be providing the means".

I thought about this for a day. The problem is that in-kernel,
single-user, multi-head is not on a good development path. That path
leads to in-kernel, multi-user support which is something I  don't
think we want to do. The current in-kernel, single-user, multi-head
feature is also only partially complete, it does not work on the
majority of VGA hardware in use today.

So the question is, what do you want to do about it? If you leave it
in place it complicates new work in the VT layer. One result being the
complicated sysfs interface that you are building. You are forced into
doing more in-kernel work to support a feature that may not be on the
long term path.

Another solution would be to build a small user space console system
and use it to drive the secondary heads. That would then allow the
feature to then be removed from the kernel. People would need to
change their scripts but the user level feature will still be there.

This is an example of a case where evolutionary design gets into
trouble. Without knowing the high-level plan for the future of
multi-user, multi-head graphics support in Linux you don't know the
right way to solve this problem.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/11/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Jon Smirl wrote:
>> > On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> >> My point is: 'Multiple active drivers feature' is a natural
>> consequence
>> >> of the evolution of the code, but the only way to take advantage of it
>> >> is if we provide a means for the user to use it.  And we are not
>> >> providing the means.
>>
>> Maybe you're misunderstanding me. When I say "we are not providing the
>> means", I mean "we are definitely not going to provide the means", NOT,
>> "so we should be providing the means".
> 
> I thought about this for a day. The problem is that in-kernel,
> single-user, multi-head is not on a good development path. That path
> leads to in-kernel, multi-user support which is something I  don't
> think we want to do. The current in-kernel, single-user, multi-head
> feature is also only partially complete, it does not work on the
> majority of VGA hardware in use today.

If you're talking about fbcon, it does work, and not just on the
minority. 

> 
> So the question is, what do you want to do about it? If you leave it
> in place it complicates new work in the VT layer.  One result being the
> complicated sysfs interface that you are building.

The VT subsystem happens to support single user, multi-head, period.
I did not add it, maybe Linus did, who knows. To use it though, besides
hacking the drivers, one needs to provide an interface for it. And I
have emphasized several times that I AM NOT going to provide one.

What I have done is to add a feature to enable us to unload the VT
drivers. If you are planning on replacing the current system with your
own, you will need this feature. So I'm doing you a favor.

> You are forced into
> doing more in-kernel work to support a feature that may not be on the
> long term path.

Look, you're saying that I should only support one driver loaded at
one time.  And I'm doing it by not allowing the users to load more
than one driver at a time. To fully kill this feature, you need to
kill the source which happens to be the VT layer.

If you don't want the VT layer to support more than 1 drivers,
go ahead, rewrite the VT layer.

> 
> Another solution would be to build a small user space console system
> and use it to drive the secondary heads. That would then allow the
> feature to then be removed from the kernel. People would need to
> change their scripts but the user level feature will still be there.

Again, go ahead.

> 
> This is an example of a case where evolutionary design gets into
> trouble. Without knowing the high-level plan for the future of
> multi-user, multi-head graphics support in Linux you don't know the
> right way to solve this problem.
> 

Nobody is stopping you from rewriting the entire graphics subsystem
from scratch.

You can be as revolutionary with your changes as you want, but you have
to respect one very important thing, kernel to userspace compatibility.

Tony

Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

[Randy.Dunlap]

On Sun, 11 Jun 2006 08:21:13 +0800 Antonino A. Daplas wrote:

> Jon Smirl wrote:
> > On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> > I may be looking at the problem a little differently. I see the
> >> > drivers like fb, vga, etc as registering with the console and saying
> >> > they are capable of providing console services. I then see the console
> >> > system as opening one of the registered devices. A driver is free to
> >> > register/unregister whenever it wants to as long as it isn't open by
> >> > the console system. Console can only open one driver at a time.
> >>
> >> No, this isn't true.  You can have multiple console drivers active,
> >> that's why you have a first and last parameter in take_over_console().
> >> Thus at boot time, the system driver will take consoles 0 - 63.
> >> Later on when a driver loads, it can take over consoles 0 - 7, leaving
> >> consoles 8 - 63 to the system driver.
> >>
> >> To put it another way, console drivers can register for consoles 0 - 63,
> >> but the user may choose to use it only for consoles 0 - 7.
> >>
> >> This is another reason for the system driver, it makes the unbinding
> >> behavior predictable.  Without a system driver, guessing which driver
> >> replaces the just unbound one may become just a tad bit confusing for
> >> the typical user.
> > 
> > I find the whole console/tty layer to be quite confusing to talk
> > about. I am mixing up console as in where printk goes and console the
> > video card login device. The part about making everything equal was
> > directed towards the printk output device.
> > 
> 
> Sorry about that, I probably should use VT or VC for the main topic
> of this thread, and plain 'console' for where the printk output goes.
> 
> This illustration might help, though I'm not sure if it's entirely
> correct. The main topic of this thread deals with the VT branch only.
> 
> Console
>    :
>    :-----:-----------:--- etc
>    :     :           :
>    VT    Serial      Net
>    :
>    :--------:-------:-----etc
>    :        :       : 
>    vgacon   fbcon   newport_con
>    :        :       :
>    :        :       :
>    hardware fbdev   hardware
>             :
>             :
>             hardware
> 
> 
> > I see now that you can have tty0-7 assigned to a different console
> > driver than tty8-63.
> > Why do I want to do this?
> 
> Multi-head.  I can have vgacon on the primary card for tty0-7,
> fbcon on the secondary card for tty8-16.
> 
> > Why do we need 64 predefined tty devices?
> 
> I don't know, but no one's stopping you to redefine MAX_NR_CONSOLES to
> a lower or higher number.
> 
> > 
> > Googling around the only example I could find was someone with a VGA
> > card and a Hercules card. They setup 8 consoles on each card.
> > 
> >> > Over time it would nice if these all merged to a single
> >> > interchangeable interface. I would really like to be able to
> >> > dynamically switch to serial/net while debugging a video driver. Is
> >> > there some fundamental reason why these can't be merged?
> >>
> >> It's already possible to redirect the system messages to two different
> >> console classes, ie with the boot parameter:
> >>
> >> console=tty0,ttyS0 /* direct output to VT and serial console */
> >>
> >> And you can already choose the console you want by adjusting
> >> /etc/inittab.
> > 
> > How can I change where printk are going at run-time? I didn't know you
> > could do that.
> 
> I really don't know.  Maybe we have some kind of entry in /proc somewhere?

If not, it should be in /sys(fs) (if being added).

fwiw, I have a patch to list all registered consoles:
http://www.xenotime.net/linux/patches/consoles-list.patch


---
~Randy