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

["Antonino A. Daplas" <adaplas@gmail.com>]

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