Messages in this thread | | | Date | Sun, 11 Jun 2006 05:26:16 +0800 | From | "Antonino A. Daplas" <> | Subject | Re: [PATCH 5/5] VT binding: Add new doc file describing the feature |
| |
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/
| |