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

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

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/