Re: VT console need rewrite

[jonsmirl@xxxxxxxxx]

On Sun, Nov 28, 2010 at 9:29 AM, Microcai <microcai@xxxxxxxxxxxxxxxxx> wrote:
> å 2010-11-28æç 09:05 -0500ïjonsmirl@xxxxxxxxxåéï
>> On Sun, Nov 28, 2010 at 8:42 AM, Microcai <microcai@xxxxxxxxxxxxxxxxx> wrote:
>> > å 2010-11-28æç 08:24 -0500ïTheodore Tsoåéï
>> >> On Nov 28, 2010, at 5:57 AM, Microcai wrote:
>> >>
>> >> > Hi, there
>> >> >
>> >> > Â Â I'm implementing the UNICODE font of the framebuffer console, (see
>> >> > http://lkml.org/lkml/2010/11/26/50 in case you do not got my email). But
>> >> > current vt code is too bugy, too many direct assumes about vt buffer,
>> >> > This makes me so hard to hack. ÂThere is TODO telling me to add UNICODE
>> >> > support, but no room for such code, that's why my patch is so tricky.
>> >> >
>> >> > Â Â And the code itself, if you'll excuse me, it isn't as beautiful as rest
>> >> > of the kernel.
>> >> > Â Â So, it really really need a clean rewrite.I'm ganna take is hard job.
>> >> > Â Â And, please tell me if is worth to do so.
>> >>
>> >> Yes, the console is code is very old. Â But please be aware that lots of code (both in the kernel and in userspace) has dependencies upon how the code behaves. Â So changing it in a way that does not break backwards compatibility is hard. Âi.e., it is hard to hack for a reason.
>> >>
>> >> I would recommend an incremental rewrite (i.e., one patch at a time), as opposed to a rewrite from scratch. Â Because people will want to be assured that things haven't broken in a horrible way as a result of a complete rewrite...
>> >>
>> >> -- Ted
>> >>
>> >
>> > Yeah, I'd also like to rewrite it incrementally. But... who will accept
>> > that incrementally patch ? It just seems that incremental patch will be
>> > horrible at the beginning...... It will be discard without a
>> > reason .....
>>
>> You can use CONFIG_VT to remove the entire VT subsystem. It might be
>> easier for you to write an alternative VT system that could be enabled
>> with a different flag.
>>
>> The VT system is very old code from the earliest days of Linux.
>> Thousands of things depend on it both in the kernel and user space. It
>> will be very hard to make significant changes to it that don't break
>> lots of dependent code.
>>
>> Another model to consider... Remove the VT subsystem. Replace it will
>> a Unicode VT system built in user space. Using the existing kernel
>> code, leave a single user console in the kernel that would only be
>> used for system maintenance. Normal users would never see this console
>> unless their system was really messed up.
>>
>>
>
> So, here is the design according to your description Â..
>
> JUST export /dev/fb and /dev/pts and /dev/console
> The kernel use /dev/console, but invisible.
> The rest of the world uses /dev/pts
>
> Make init using /dev/fb to display boot message, and agetty runs
> on /dev/pts
>
> Another user-space program use /dev/fb to display all /dev/pts , you can
> use alt+Fx to switch between them (kernel no longer handles console
> switch).
>
> So, there is no virtual console ... . Just as windows Â(who uses cmd.exe
> to display console )
>
> kernel just deal with BYTE stream, no need for font handling .....
>
> Will you agree with that kind of system ?

It is a lot of work to get a system like that running, but it should
work when finished. It also lets you avoid messing with the VT layer
which will be a very painful process.

Now that we have KMS you can even hide the boot display if you want.
My Ubuntu system jumps straight to a graphical boot display and you
have to hit a key to see the boot console.



>
>
>
>
>
>



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/