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

["Jon Smirl" <jonsmirl@gmail.com>]

On 6/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> 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.

An example might help clarify this.

Imagine that you have three console drivers (vga, serial, fb) and one
console system all implemented as modules. I'm not saying make console
a module, just pretend like it is one.

First you would modprobe in the console system.
Next modprobe in the three console drivers which automatically
register with the console system.

At this point the console system would have a ref count of 3. It can
not be unloaded until the three console drivers have unregistered.

Now console opens the vga console driver, that will increment the ref
count on that driver.

Now switch to the serial driver, ref count will go to zero on vga and
one one serial.

At this point vga and fb could be unloaded if they were modules.

If console contains the rule that it always has to keep a console
open, it will be bound into memory since it will never be possible to
get its ref count to zero.

In the old model take_over_console() effectively combined these refs
counts so that it was impossible to unload anything once it was
loaded. There was no mechanism to decrement the ref count on the
console drivers.


-- 
Jon Smirl
jonsmirl@gmail.com