Menu
▾
▴
linuxconsole-dev
|
From: James S. <jsi...@ac...> - 2000-03-07 19:49:06
|
Howdy!!! First its time to register developers. Please send me or Eric Raymond a email with your sourceforge account username. We will add you to the developement list. We also have to organize who is going to do what. So far I know I will be working on the fbdev/fbcon and multihead support part. Dominik Kubla wants to work on proper VT 100 and other types of term emulations. Raymond is going to be working on our web site, documentation, and more terminal emulation stuff. I assume Vojtech is going to continue his input work. Everyone is welcomed so step forward and tell what parts you want to work on. Remember this a group project and we all have worked in group projects so I don't have to spell out how CVS developement is done. Think 3 times before you commit and discuss your ideas/changes with everyone. Well its time to discuss which tree to use. Some people spoke of the 2.2.X. Other want to work on the 2.3.X branch. Well their are pros and cons to both. The 2.2.X kernels are stable so we don't have to worry to much about keeping in sync with any important changes. The draw back is except for bug fixes alot of our changes wouldn't be back ported. Also the changes I'm doing to fbdev where I'm moving the console code out of the fbdev drivers into fbcon.c will not be there. This means if we change things we might have to update all the fbdev drivers from time to time. Same is true even for the 2.3.X tree for the input device drivers. This might change if and when Vojtech work is incorporated into 2.3.X. If we go with the 2.3.X and if Vojtech work goes in and I finish changing the fbdev API we have the pro of not breaking any important drivers all the time. Only a handful of files to change. The con is we have to keep up with any important changes all the time. The next big issue is what do we place in CVS. The whole kernel tree or just certain branches. Downloading via CVS a whole kernel the first time is not going to be fun if you have a cheesy modem. Of course we have to deal with docs for people who want to try the console code and have to patch their kernels. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Eric S. R. <es...@th...> - 2000-03-07 21:54:01
|
James Simmons <jsi...@ac...>: > We also have to organize who is going to do what. So > far I know I will be working on the fbdev/fbcon and multihead support > part. Dominik Kubla wants to work on proper VT 100 and other types of > term emulations. Raymond is going to be working on our web site, > documentation, and more terminal emulation stuff. I assume Vojtech is > going to continue his input work. These are the assumptions on the web page I'm drafting. > Well its time to discuss which tree to use. Some people spoke of the > 2.2.X. Other want to work on the 2.3.X branch. Well their are pros and > cons to both. The 2.2.X kernels are stable so we don't have to worry to > much about keeping in sync with any important changes. The draw back is > except for bug fixes alot of our changes wouldn't be back ported. Also > the changes I'm doing to fbdev where I'm moving the console code out of > the fbdev drivers into fbcon.c will not be there. This means if we change > things we might have to update all the fbdev drivers from time to time. > Same is true even for the 2.3.X tree for the input device drivers. This > might change if and when Vojtech work is incorporated into 2.3.X. > If we go with the 2.3.X and if Vojtech work goes in and I finish > changing the fbdev API we have the pro of not breaking any important > drivers all the time. Only a handful of files to change. The con is we > have to keep up with any important changes all the time. It seems to me that we have three deliverables: 1. console.c and man page patches for 2.2.x to fix ANSI conformance in the terminal emulation. These need to go to Alan Cox for merge into the old stable tree. I think Dominik has already done this work. It needs to be tested and documented, which is my job. 2. console.c and man page patches for 2.3.x to fix ANSI conformance in the terminal emulation. These need to go to Linus for inclusion before 2.4. Likewise I think Dominik has already done this work. 3. A line of patches for 2.4.x that implements the heavy stuff; fbdev refactoring, multihead, scrollback, etc. These can't go in until 2.5.x. These things are what I'm going to list as deliverables on the project web page, unless somebody objects. > The next big issue is what do we place in CVS. The whole kernel tree or > just certain branches. Downloading via CVS a whole kernel the first time > is not going to be fun if you have a cheesy modem. Of course we have to > deal with docs for people who want to try the console code and have to > patch their kernels. I don't have enough kernel-hacking experience to have an opinion about this. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Hitler, April 11 1942, revealing the real agenda of "gun control" |
|
From: James S. <jsi...@ac...> - 2000-03-08 00:48:45
|
> > The next big issue is what do we place in CVS. The whole kernel tree or > > just certain branches. Downloading via CVS a whole kernel the first time > > is not going to be fun if you have a cheesy modem. Of course we have to > > deal with docs for people who want to try the console code and have to > > patch their kernels. > > I don't have enough kernel-hacking experience to have an opinion about > this. Thinking about creating a console directory for now and a diff against various kernel versions. Opinions? "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Dominik K. <dom...@un...> - 2000-03-08 07:32:29
|
On Tue, Mar 07, 2000 at 07:54:08PM -0500, James Simmons wrote: ... > Thinking about creating a console directory for now and a diff against > various kernel versions. Opinions? Just what i wanted to propose. Another note regarding coding style: All _exported_ functions and variables need to have constant name prefix. I propose the following: con_ console device (already used for this) kb_ keyboard driver vt_ virtual terminal handling (already used for this) vte_ video terminal emulation Comments? Eric, what format should we use for the docs? Plain text? Nroff? I would discount TeX and SGML because people can not be expected to have these tools installed, even so one could use a SGML subset and sed/awk scripts to convert them to text. Since man pages are already written in nroff and nroff is generating decent printer output (and since it's the Unix standard way of delivering documents anyway), i would propose to use nroff for the other docs to be included into the kernel as well. And i recall you are well versed in nroff anyway... ;-) So i see the following directory structure for now Documentation/console The documentation drivers/char/console The generic console code Dominik -- Networking Group, Hospital of Johannes Gutenberg-University Obere Zahlbacher Straße 69, 55101 Mainz, Germany Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521 |
|
From: Eric S. R. <es...@th...> - 2000-03-08 07:47:11
|
Dominik Kubla <dom...@un...>: > All _exported_ functions and variables need to have constant name prefix. > I propose the following: > > con_ console device (already used for this) > kb_ keyboard driver > vt_ virtual terminal handling (already used for this) > vte_ video terminal emulation > > Comments? Good idea. > Eric, what format should we use for the docs? Plain text? Nroff? I would > discount TeX and SGML because people can not be expected to have these > tools installed, even so one could use a SGML subset and sed/awk scripts > to convert them to text. Since man pages are already written in nroff > and nroff is generating decent printer output (and since it's the Unix > standard way of delivering documents anyway), i would propose to use nroff > for the other docs to be included into the kernel as well. And i recall > you are well versed in nroff anyway... ;-) Nroff should be fine for this application. Anyway, the only documentation change I was immediately planning was an update to console_codes(4). -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical." -- Thomas Jefferson, Letter to James Madison, January 30, 1787 |
|
From: Dominik K. <dom...@un...> - 2000-03-08 08:12:58
|
On Wed, Mar 08, 2000 at 02:46:03AM -0500, Eric S. Raymond wrote: ... > Nroff should be fine for this application. Anyway, the only documentation > change I was immediately planning was an update to console_codes(4). I will most definitely contribute the beginnings of a programmers reference manual for the terminal emulation. And since i intend to document all changes in the kernel code, we could start with section 9 again, if we were so inclined. I recall Linus being less appreciative of the idea of using embedded docs and automatic tools to generate man pages, but that might have changed since it was mentionend the last time... Dominik -- Networking Group, Hospital of Johannes Gutenberg-University Obere Zahlbacher Straße 69, 55101 Mainz, Germany Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521 |
|
From: Eric S. R. <es...@th...> - 2000-03-08 08:20:40
|
Dominik Kubla <dom...@un...>: > I will most definitely contribute the beginnings of a programmers reference > manual for the terminal emulation. And since i intend to document all changes > in the kernel code, we could start with section 9 again, if we were so inclined. By "a programmers reference manual for the terminal emulation", do you mean a description of the supported escape sequences? > I recall Linus being less appreciative of the idea of using embedded docs > and automatic tools to generate man pages, but that might have changed since > it was mentionend the last time... I believe Alan Cox is pushing some tools for doing this. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry |
|
From: Dominik K. <dom...@un...> - 2000-03-08 08:46:48
|
On Wed, Mar 08, 2000 at 03:19:33AM -0500, Eric S. Raymond wrote: > By "a programmers reference manual for the terminal emulation", do you mean a > description of the supported escape sequences? With annotations regarding recommended use and implementation specifics. Just like the respective DEC manuals, but i think we can skip the users manual ;-) Oh, i see! That's what console_codes(4) already does ... > > I recall Linus being less appreciative of the idea of using embedded docs > > and automatic tools to generate man pages, but that might have changed since > > it was mentionend the last time... > > I believe Alan Cox is pushing some tools for doing this. Got any pointers on what he is using? Dominik -- Networking Group, Hospital of Johannes Gutenberg-University Obere Zahlbacher Straße 69, 55101 Mainz, Germany Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521 |
|
From: Eric S. R. <es...@th...> - 2000-03-08 08:51:06
|
Dominik Kubla <dom...@un...>: > On Wed, Mar 08, 2000 at 03:19:33AM -0500, Eric S. Raymond wrote: > > > By "a programmers reference manual for the terminal emulation", do you mean a > > description of the supported escape sequences? > > With annotations regarding recommended use and implementation specifics. > Just like the respective DEC manuals, but i think we can skip the users > manual ;-) > > Oh, i see! That's what console_codes(4) already does ... Yes, asnd I've almost finished tabulating the changes in your 2.2.1 patch. > Got any pointers on what he is using? No, but you could ask him. He doesn't bite :-). -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> ...Virtually never are murderers the ordinary, law-abiding people against whom gun bans are aimed. Almost without exception, murderers are extreme aberrants with lifelong histories of crime, substance abuse, psychopathology, mental retardation and/or irrational violence against those around them, as well as other hazardous behavior, e.g., automobile and gun accidents." -- Don B. Kates, writing on statistical patterns in gun crime |
|
From: James S. <jsi...@ac...> - 2000-03-08 15:58:15
|
On Wed, 8 Mar 2000, Dominik Kubla wrote: > On Tue, Mar 07, 2000 at 07:54:08PM -0500, James Simmons wrote: > ... > > Thinking about creating a console directory for now and a diff against > > various kernel versions. Opinions? > > Just what i wanted to propose. Another note regarding coding style: Thats solved. > All _exported_ functions and variables need to have constant name prefix. > I propose the following: > > con_ console device (already used for this) > kb_ keyboard driver > vt_ virtual terminal handling (already used for this) > vte_ video terminal emulation Looks good. Should we go with vt_ or vc_ since in theory you could have virtual consoles on serial consoles as well? Or have virtual terminal handling only for video terminals. I also assume this is for now. the "ruby" series will different for kb_ since this will be intergrated with Vojtech's work. P.S Vojtech I tried your patch against 2.3.50-3. It bomded. I was wondering if you updated it already so we don't duplicate effort here. "Look it's a text editor, not it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Dominik K. <dom...@un...> - 2000-03-08 16:23:53
|
On Wed, Mar 08, 2000 at 11:03:42AM -0500, James Simmons wrote: > P.S > > Vojtech I tried your patch against 2.3.50-3. It bomded. I was wondering > if you updated it already so we don't duplicate effort here. Working on it... But right now i have to check my defences: some cracker scanned our University and i have to make sure my external systems are secured. Dominik -- Networking Group, Hospital of Johannes Gutenberg-University Obere Zahlbacher Straße 69, 55101 Mainz, Germany Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521 |
|
From: Dominik K. <dom...@un...> - 2000-03-08 18:43:58
|
On Wed, Mar 08, 2000 at 05:19:22PM +0100, Dominik Kubla wrote: > On Wed, Mar 08, 2000 at 11:03:42AM -0500, James Simmons wrote: > > P.S > > > > Vojtech I tried your patch against 2.3.50-3. It bomded. I was wondering > > if you updated it already so we don't duplicate effort here. > > Working on it... But right now i have to check my defences: some cracker > scanned our University and i have to make sure my external systems are > secured. Argh! Too much to do to even understand the mails i am replying to... What i meant is: i am working on the 2.3.50 version of the vt100-related stuff. I simply misread that this part of the mail was directed at Vojtech. *GRUMBLE* Dominik -- Networking Group, Hospital of Johannes Gutenberg-University Obere Zahlbacher Straße 69, 55101 Mainz, Germany Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521 |
|
From: Vojtech P. <vo...@su...> - 2000-03-08 18:34:25
|
On Wed, Mar 08, 2000 at 11:03:42AM -0500, James Simmons wrote: > Looks good. Should we go with vt_ or vc_ since in theory you could have > virtual consoles on serial consoles as well? Or have virtual terminal > handling only for video terminals. I also assume this is for now. the > "ruby" series will different for kb_ since this will be intergrated with > Vojtech's work. > > > P.S > > Vojtech I tried your patch against 2.3.50-3. It bomded. I was wondering > if you updated it already so we don't duplicate effort here. I did not yet. However, I have updated most of the drivers in it quite a bit and I'll be releasing an updated patch rather soon hopefully. -- Vojtech Pavlik SuSE Labs |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X