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.
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
... 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.
> 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?
> 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.
What do you think?
Am I making more sense now?
--
Jon Smirl
[email protected]
-
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]
