Jon Smirl wrote:
> On 6/10/06, Antonino A. Daplas <[email protected]> wrote:
>> Jon Smirl wrote:
>> > On 6/9/06, Antonino A. Daplas <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
