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

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

Jon Smirl wrote:
> On 6/11/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Jon Smirl wrote:
>> > On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> >> My point is: 'Multiple active drivers feature' is a natural
>> consequence
>> >> of the evolution of the code, but the only way to take advantage of it
>> >> is if we provide a means for the user to use it.  And we are not
>> >> providing the means.
>>
>> Maybe you're misunderstanding me. When I say "we are not providing the
>> means", I mean "we are definitely not going to provide the means", NOT,
>> "so we should be providing the means".
> 
> I thought about this for a day. The problem is that in-kernel,
> single-user, multi-head is not on a good development path. That path
> leads to in-kernel, multi-user support which is something I  don't
> think we want to do. The current in-kernel, single-user, multi-head
> feature is also only partially complete, it does not work on the
> majority of VGA hardware in use today.

If you're talking about fbcon, it does work, and not just on the
minority. 

> 
> So the question is, what do you want to do about it? If you leave it
> in place it complicates new work in the VT layer.  One result being the
> complicated sysfs interface that you are building.

The VT subsystem happens to support single user, multi-head, period.
I did not add it, maybe Linus did, who knows. To use it though, besides
hacking the drivers, one needs to provide an interface for it. And I
have emphasized several times that I AM NOT going to provide one.

What I have done is to add a feature to enable us to unload the VT
drivers. If you are planning on replacing the current system with your
own, you will need this feature. So I'm doing you a favor.

> You are forced into
> doing more in-kernel work to support a feature that may not be on the
> long term path.

Look, you're saying that I should only support one driver loaded at
one time.  And I'm doing it by not allowing the users to load more
than one driver at a time. To fully kill this feature, you need to
kill the source which happens to be the VT layer.

If you don't want the VT layer to support more than 1 drivers,
go ahead, rewrite the VT layer.

> 
> Another solution would be to build a small user space console system
> and use it to drive the secondary heads. That would then allow the
> feature to then be removed from the kernel. People would need to
> change their scripts but the user level feature will still be there.

Again, go ahead.

> 
> This is an example of a case where evolutionary design gets into
> trouble. Without knowing the high-level plan for the future of
> multi-user, multi-head graphics support in Linux you don't know the
> right way to solve this problem.
> 

Nobody is stopping you from rewriting the entire graphics subsystem
from scratch.

You can be as revolutionary with your changes as you want, but you have
to respect one very important thing, kernel to userspace compatibility.

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/