From: Microcai <microcai@fedoraproject.org>
To: Ted Ts'o <tytso@mit.edu>
Cc: Lisa Milne <lisa@ltmnet.com>,
"jonsmirl@gmail.com" <jonsmirl@gmail.com>,
linux-kernel@vger.kernel.org, linux-console@vger.kernel.org
Subject: Re: VT console need rewrite
Date: Mon, 29 Nov 2010 09:14:04 +0800 [thread overview]
Message-ID: <1290993244.877.3.camel@cai.gentoo> (raw)
In-Reply-To: <20101128194624.GP2767@thunk.org>
在 2010-11-28日的 14:46 -0500,Ted Ts'o写道:
> On Mon, Nov 29, 2010 at 12:20:07AM +0800, Microcai wrote:
> >
> > > Another possible model: split the current system in 2, so there's a
> > > bytestream handler, and a vt-legacy module. Then use the interface
> > > between bytestream/legacy as an interface for future vt-kernel and
> > > vt-user modules.
> >
> > this may cause early printk stop working.
>
> Let's start by asking a much more fundamental question; what the heck
> are your goals?
>
> If the main goal of the console is emergency debugging when the system
> is in a very bad state (i.e., trashed initrd, etc.) do we really even
> need Unicode support?
>
> How many people do regular login, development, reading e-mail, etc.,
> on the console? Very few! If the answer is because you hate X, as
> you've already pointed out, we already have fbterm. Where is it
> written that we need to have a full unicode-capable console system?
> Why is this so important; especially if doing this is going to be very
> difficult, and risks breaking lots of stuff if we try to mess with it?
>
> - Ted
Hey, my old patch already did it , and do not break any old stuff.
Question is , the VT code *is really very old*.
Just want to simplify the code, remove old stuff, make it future
compatible. Forward compatibility is more important than backward one
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Microcai <microcai@fedoraproject.org>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Lisa Milne <lisa@ltmnet.com>,
"jonsmirl@gmail.com" <jonsmirl@gmail.com>,
linux-kernel@vger.kernel.org, linux-console@vger.kernel.org
Subject: Re: VT console need rewrite
Date: Mon, 29 Nov 2010 09:14:04 +0800 [thread overview]
Message-ID: <1290993244.877.3.camel@cai.gentoo> (raw)
In-Reply-To: <20101128194624.GP2767@thunk.org>
在 2010-11-28日的 14:46 -0500,Ted Ts'o写道:
> On Mon, Nov 29, 2010 at 12:20:07AM +0800, Microcai wrote:
> >
> > > Another possible model: split the current system in 2, so there's a
> > > bytestream handler, and a vt-legacy module. Then use the interface
> > > between bytestream/legacy as an interface for future vt-kernel and
> > > vt-user modules.
> >
> > this may cause early printk stop working.
>
> Let's start by asking a much more fundamental question; what the heck
> are your goals?
>
> If the main goal of the console is emergency debugging when the system
> is in a very bad state (i.e., trashed initrd, etc.) do we really even
> need Unicode support?
>
> How many people do regular login, development, reading e-mail, etc.,
> on the console? Very few! If the answer is because you hate X, as
> you've already pointed out, we already have fbterm. Where is it
> written that we need to have a full unicode-capable console system?
> Why is this so important; especially if doing this is going to be very
> difficult, and risks breaking lots of stuff if we try to mess with it?
>
> - Ted
Hey, my old patch already did it , and do not break any old stuff.
Question is , the VT code *is really very old*.
Just want to simplify the code, remove old stuff, make it future
compatible. Forward compatibility is more important than backward one
next prev parent reply other threads:[~2010-11-29 1:14 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-28 10:57 VT console need rewrite Microcai
2010-11-28 13:24 ` Theodore Tso
2010-11-28 13:42 ` Microcai
2010-11-28 13:42 ` Microcai
2010-11-28 14:05 ` jonsmirl
2010-11-28 14:05 ` jonsmirl
2010-11-28 14:29 ` Microcai
2010-11-28 14:29 ` Microcai
2010-11-28 14:49 ` jonsmirl
2010-11-28 14:49 ` jonsmirl
2010-11-28 19:11 ` Samuel Thibault
2010-11-29 1:10 ` Microcai
2010-11-29 1:10 ` Microcai
2010-11-29 2:49 ` Américo Wang
2010-11-29 2:49 ` Américo Wang
2010-11-29 2:48 ` Microcai
2010-11-29 2:48 ` Microcai
2010-11-29 8:16 ` Samuel Thibault
2010-11-29 8:16 ` Samuel Thibault
2010-11-29 8:20 ` microcai
2010-11-29 8:20 ` microcai
2010-11-29 8:27 ` Samuel Thibault
2010-11-29 8:53 ` Microcai
2010-11-29 8:53 ` Microcai
2010-11-29 8:59 ` Samuel Thibault
2010-11-29 8:59 ` Samuel Thibault
2010-11-28 16:06 ` Lisa Milne
2010-11-28 16:20 ` Microcai
2010-11-28 19:46 ` Ted Ts'o
2010-11-29 1:14 ` Microcai [this message]
2010-11-29 1:14 ` Microcai
2010-11-29 8:58 ` Samuel Thibault
2010-11-29 8:58 ` Samuel Thibault
2010-11-29 9:32 ` Microcai
2010-11-29 9:32 ` Microcai
2010-11-29 9:58 ` Samuel Thibault
2010-11-29 10:11 ` Microcai
2010-11-29 10:11 ` Microcai
2010-11-29 10:17 ` Samuel Thibault
2010-11-29 10:40 ` Microcai
2010-11-29 10:40 ` Microcai
2010-11-29 10:39 ` Samuel Thibault
2010-11-29 10:39 ` Samuel Thibault
2010-12-15 14:45 ` Pavel Machek
2010-12-15 14:45 ` Pavel Machek
2010-12-15 15:04 ` Samuel Thibault
2010-12-15 15:04 ` Samuel Thibault
2010-11-29 1:55 ` Alexey Gladkov
2010-11-29 1:55 ` Alexey Gladkov
2010-11-29 2:14 ` Microcai
2010-11-29 14:02 ` Alan Cox
2010-11-29 17:50 ` Valdis.Kletnieks
2010-11-29 21:23 ` Jerome Glisse
2010-11-29 21:23 ` Jerome Glisse
2010-11-28 23:46 ` Alan Cox
2010-11-29 1:28 ` Microcai
2010-11-29 1:28 ` Microcai
2010-11-29 14:07 ` Alan Cox
2010-11-30 5:05 ` microcai
2010-12-20 6:35 ` Pavel Machek
2010-11-29 10:01 ` Andi Kleen
2010-11-29 10:12 ` Microcai
2010-11-29 10:12 ` Microcai
2010-12-07 20:37 ` Jesse Barnes
2010-12-13 7:13 ` Pavel Machek
2010-12-13 10:18 ` Alan Cox
2010-12-15 14:40 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1290993244.877.3.camel@cai.gentoo \
--to=microcai@fedoraproject.org \
--cc=jonsmirl@gmail.com \
--cc=linux-console@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lisa@ltmnet.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.