VT binding: Add new doc file describing the feature
Subsystems (2)
PATCH 5/5 VT binding: Add new doc file describing the feature
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
---
Documentation/console/console.txt | 127 +++++++++++++++++++++++++++++++++++++ 1 files changed, 127 insertions(+), 0 deletions(-)
Documentation/console/console.txt new file +127 -0
@@ -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 <[email protected]> +
Quoted 3 lines · Antonino A. Daplas
- 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
Signature · 2 lines
Jon Smirl [email protected]
Quoted 5 lines · Jon Smirl
Quoted 3 lines · Antonino A. Daplas
- 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
Quoted 8 lines
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.
Quoted 1 line
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.
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 8 lines
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.
Quoted 14 lines
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
Quoted 8 lines
cat
/sys/class/tty/console/backend
vgaecho 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
Quoted 15 lines · Antonino A. Daplas
Quoted 5 lines · Jon Smirl
Quoted 3 lines · Antonino A. Daplas
- Describe the characteristics of 2 general types of console drivers
- How to use the sysfs to unbind and bind console drivers
- Uses for this featureQuoted 8 lines
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.
Quoted 1 line
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.
Quoted 7 lines
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.
Quoted 11 lines
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.
Quoted 8 lines
Quoted 3 lines
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?
Quoted 7 lines
Quoted 3 lines
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.
Quoted 1 line
What do you think?
Am I making more sense now?
Signature · 2 lines
Jon Smirl [email protected]
Quoted 5 lines · Jon Smirl
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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 8 lines · Jon Smirl
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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 22 lines · Jon Smirl
Quoted 21 lines · Antonino A. Daplas
Quoted 5 lines · Jon Smirl
Quoted 3 lines · Antonino A. Daplas
- Describe the characteristics of 2 general types of console drivers
- How to use the sysfs to unbind and bind console drivers
- Uses for this featureQuoted 8 lines
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.
Quoted 1 line
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 12 lines
Opening another driver automatically closes the previous driver and one driver always has to be open.
Quoted 9 lines
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
:
--- vtcon1Each class device file has 2 attributes:
bind - r/w attribute
name - description of the current backend
Quoted 5 lines
Quoted 2 lines
... 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.
Quoted 2 lines
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.
Quoted 23 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 4 lines
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
Quoted 13 lines · Antonino A. Daplas
Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 11 lines
Quoted 4 lines
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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 22 lines · Jon Smirl
Quoted 13 lines · Antonino A. Daplas
Quoted 6 lines
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.Quoted 7 lines
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.
Quoted 5 lines
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
:
:
hardwareQuoted 3 lines
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.
Quoted 1 line
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.
Quoted 12 lines
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.
Quoted 8 lines
Quoted 4 lines
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:
Quoted 7 lines
Quoted 4 lines
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
Quoted 6 lines · Antonino A. Daplas
Quoted 3 lines
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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 8 lines · Jon Smirl
Quoted 6 lines · Antonino A. Daplas
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 4 lines
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.
Quoted 9 lines
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
[email protected]
Signature · 2 lines
Jon Smirl [email protected]
Quoted 8 lines · Jon Smirl
Quoted 6 lines · Antonino A. Daplas
Quoted 3 lines
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.
Quoted 7 lines
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 :-)
Quoted 5 lines
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.)
Quoted 5 lines
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
Quoted 4 lines · Antonino A. Daplas
Quoted 2 lines
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?
Console redirection can be asked for with the TIOCCONS ioctl(), this is for example used by "xterm -C". I am not sure how to manipulate the system list of console destinations.
Gruss
Bernd
Quoted 6 lines · Jon Smirl
Quoted 5 lines · Jon Smirl
Quoted 4 lines · Antonino A. Daplas
Quoted 3 lines
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?
Quoted 8 lines
Quoted 3 lines
Quoted 2 lines
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
Quoted 13 lines · Antonino A. Daplas
Quoted 12 lines · Jon Smirl
Quoted 6 lines · Antonino A. Daplas
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
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/fb0to tty0-3 and/dev/fb1to 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.
Quoted 9 lines
Quoted 4 lines
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.
Quoted 2 lines
(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?
Quoted 21 lines
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.)
Quoted 5 lines
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
Signature · 2 lines
Jon Smirl [email protected]
Quoted 18 lines · Antonino A. Daplas
Quoted 6 lines · Jon Smirl
Quoted 5 lines · Jon Smirl
Quoted 4 lines · Antonino A. Daplas
Quoted 3 lines
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?Quoted 8 lines
Quoted 3 lines
Quoted 2 lines
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:
Quoted 8 lines
"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()inmdacon.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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 18 lines · Jon Smirl
Quoted 17 lines · Antonino A. Daplas
Quoted 15 lines · Jon Smirl
Quoted 6 lines · Antonino A. Daplas
Quoted 3 lines
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?
Quoted 7 lines
Quoted 4 lines
matroxfb supports multihead and fbcon already has this feature for a long time, ie you can bind
/dev/fb0to tty0-3 and/dev/fb1to 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.
Quoted 5 lines
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.
Quoted 13 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 7 lines
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.
Quoted 2 lines
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.
Quoted 9 lines
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
Quoted 35 lines · Jon Smirl
Quoted 18 lines · Antonino A. Daplas
Quoted 6 lines · Jon Smirl
Quoted 5 lines · Jon Smirl
Quoted 4 lines · Antonino A. Daplas
Quoted 3 lines
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?Quoted 8 lines
Quoted 3 lines
Quoted 2 lines
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:
Quoted 8 lines
"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()inmdacon.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.
Quoted 7 lines
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
Quoted 78 lines · On Sun, 11 Jun 2006 08:21:13 +0800 Antonino A. Daplas wrote:
Quoted 22 lines · Jon Smirl
Quoted 13 lines · Antonino A. Daplas
Quoted 6 lines
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.Quoted 7 lines
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.
Quoted 5 lines
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 : : hardwareQuoted 3 lines
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.
Quoted 1 line
Why do we need 64 predefined tty devices?
I don't know, but no one's stopping you to redefine
MAX_NR_CONSOLESto a lower or higher number.Quoted 14 lines
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.
Quoted 10 lines
Quoted 4 lines
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 */
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 4 lines · Antonino A. Daplas
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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 10 lines · Jon Smirl
Quoted 4 lines · Antonino A. Daplas
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.
Quoted 5 lines
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
Quoted 5 lines · Jon Smirl
Quoted 4 lines · Antonino A. Daplas
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
Quoted 10 lines · Antonino A. Daplas
Quoted 5 lines · Jon Smirl
Quoted 4 lines · Antonino A. Daplas
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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 13 lines · Jon Smirl
Quoted 11 lines · Antonino A. Daplas
Quoted 2 lines · Jon Smirl
Quoted 1 line · Antonino A. Daplas
My point is: 'Multiple active drivers feature' is a natural
consequence
Quoted 3 lines
Quoted 3 lines
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".
Quoted 6 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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
Quoted 18 lines · Antonino A. Daplas
Quoted 6 lines · Jon Smirl
Quoted 5 lines · Jon Smirl
Quoted 4 lines · Antonino A. Daplas
Quoted 3 lines
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?Quoted 8 lines
Quoted 3 lines
Quoted 2 lines
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:
Quoted 8 lines
"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()inmdacon.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 -- [email protected]
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