Menu
▾
▴
linuxconsole-dev
|
From: Zoltan B. <zb...@fr...> - 2005-02-20 17:39:31
Attachments:
ruby-2.6.11-rc4.diff.bz2
|
Hi, as large console cleanups went into the -mm tree and those cleanups are also part of the Ruby tree, I thought I look at the Ruby tree and port it to 2.6.11-rc4 + the following 4 patches: 1. cleanup-vc-array-access.patch 2. remove-console_macrosh.patch 3. merge-vt_struct-into-vc_data.patch 4. merge-vt_struct-into-vc_data-fix.patch In the porting, I followed these rules: - no major cleanups, including: - no function shuffling around - no function and variable renames - no DECVTE, keep the old Linux terminal emulation. The only cleanup I applied was the redraw_screen() function splitup to update_screen() and switch_screen() so they can be static where they are used. The result is a very straightforward patch that is about 18K smaller than the first two cleanup patches added (~ 142000 bytes vs ~ 160000 bytes). The catch is that it doesn't boot up successfully despite I tried to follow the changes in the Ruby tree exactly. With only the VGA console, I got a message about "unable to open initial console" the SELinux messages and booting stopped there. With "dumbcon=3D1", I got an oops with this stacktrace: init vty_init dumb_console_init dumbcon_add vt_map_display and I also got two messages: unblank_screen: tty not allocated ?? Maybe it rings a bell for someone and can fix it. I expect at most two one-liners over this patch to have a working Ruby kernel. I Cc-ed all interested parties, including Roman Zippel who expressed interest to look into the Ruby tree after all these cleanups went mainline. Happy hacking, Roman! :-) Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Zoltan B. <zb...@fr...> - 2005-02-20 19:01:28
|
Sorry, there's a missing word that made one of the sentences not understandable. Zoltan Boszormenyi =EDrta: > The catch is that it doesn't boot up successfully despite I tried > to follow the changes in the Ruby tree exactly. With only the VGA > console, I got a message about "unable to open initial console" "before" > the SELinux messages and booting stopped there. |
|
From: Aivils <ai...@un...> - 2005-02-21 07:44:07
|
Hi, Zoltan! This patch needs for line per line walkthrough. I will start today. I hope complete it during one week. I am not sure about fbcon. fbcon may takes more work. Aivils On Sunday 20 February 2005 19:46, Zoltan Boszormenyi wrote: > Hi, >=20 > as large console cleanups went into the -mm tree and those cleanups > are also part of the Ruby tree, I thought I look at the Ruby tree > and port it to 2.6.11-rc4 + the following 4 patches: >=20 > 1. cleanup-vc-array-access.patch > 2. remove-console_macrosh.patch > 3. merge-vt_struct-into-vc_data.patch > 4. merge-vt_struct-into-vc_data-fix.patch >=20 > In the porting, I followed these rules: > - no major cleanups, including: > - no function shuffling around > - no function and variable renames > - no DECVTE, keep the old Linux terminal emulation. >=20 > The only cleanup I applied was the redraw_screen() function > splitup to update_screen() and switch_screen() so they can be > static where they are used. >=20 > The result is a very straightforward patch that is about 18K smaller > than the first two cleanup patches added (~ 142000 bytes vs ~ 160000 > bytes). >=20 > The catch is that it doesn't boot up successfully despite I tried > to follow the changes in the Ruby tree exactly. With only the VGA > console, I got a message about "unable to open initial console" > the SELinux messages and booting stopped there. With "dumbcon=3D1", > I got an oops with this stacktrace: >=20 > init > vty_init > dumb_console_init > dumbcon_add > vt_map_display >=20 > and I also got two messages: >=20 > unblank_screen: tty not allocated ?? >=20 > Maybe it rings a bell for someone and can fix it. I expect at most > two one-liners over this patch to have a working Ruby kernel. >=20 > I Cc-ed all interested parties, including Roman Zippel who expressed > interest to look into the Ruby tree after all these cleanups went > mainline. Happy hacking, Roman! :-) >=20 > Best regards, > Zolt=E1n B=F6sz=F6rm=E9nyi >=20 |
|
From: Zoltan B. <zb...@fr...> - 2005-02-21 17:46:11
|
Hi, Aivil! Aivils =EDrta: > Hi, Zoltan! >=20 > This patch needs for line per line walkthrough. I will start > today. I hope complete it during one week. That's what I did with your original patch against the kernel. ;-) It took my almost three days. > I am not sure about fbcon. fbcon may takes more work. I havent't even dared to touch that area... The final goal is to have a multiconsole-capable Linux kernel, so the size of the patch matters, that's why I did it this way. BTW, you can find the four patches I mentioned here: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3= /2.6.11-rc3-mm2/broken-out/ Apply them in the order I listed. BTW the patch I attached applied against the whole 2.6.11-rc3-mm2 creates only two small and trivial rejects. Thanks for looking into it, I won't have more time to work on it in the near future. > Aivils > On Sunday 20 February 2005 19:46, Zoltan Boszormenyi wrote: >=20 >>Hi, >> >>as large console cleanups went into the -mm tree and those cleanups >>are also part of the Ruby tree, I thought I look at the Ruby tree >>and port it to 2.6.11-rc4 + the following 4 patches: >> >>1. cleanup-vc-array-access.patch >>2. remove-console_macrosh.patch >>3. merge-vt_struct-into-vc_data.patch >>4. merge-vt_struct-into-vc_data-fix.patch >> >>In the porting, I followed these rules: >>- no major cleanups, including: >> - no function shuffling around >> - no function and variable renames >>- no DECVTE, keep the old Linux terminal emulation. >> >>The only cleanup I applied was the redraw_screen() function >>splitup to update_screen() and switch_screen() so they can be >>static where they are used. >> >>The result is a very straightforward patch that is about 18K smaller >>than the first two cleanup patches added (~ 142000 bytes vs ~ 160000 >>bytes). >> >>The catch is that it doesn't boot up successfully despite I tried >>to follow the changes in the Ruby tree exactly. With only the VGA >>console, I got a message about "unable to open initial console" >>the SELinux messages and booting stopped there. With "dumbcon=3D1", >>I got an oops with this stacktrace: >> >>init >>vty_init >>dumb_console_init >>dumbcon_add >>vt_map_display >> >>and I also got two messages: >> >>unblank_screen: tty not allocated ?? >> >>Maybe it rings a bell for someone and can fix it. I expect at most >>two one-liners over this patch to have a working Ruby kernel. >> >>I Cc-ed all interested parties, including Roman Zippel who expressed >>interest to look into the Ruby tree after all these cleanups went >>mainline. Happy hacking, Roman! :-) >> >>Best regards, >>Zolt=E1n B=F6sz=F6rm=E9nyi >> >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick > _______________________________________________ > Linuxconsole-dev mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev >=20 >=20 |
|
From: James S. <jsi...@ww...> - 2005-02-21 22:00:13
|
> This patch needs for line per line walkthrough. I will start > today. I hope complete it during one week. > I am not sure about fbcon. fbcon may takes more work. Fbcon is alot of work. A few more changes are planned for it in the near future as we are preparing OpenGL to run on top of fbdev/drm. I have been keeping the linuxconsole BK tree up to date. The only difference between are tree is I have the number of Vc per VT a static 16 always. |
|
From: Aivils <ai...@un...> - 2005-02-24 07:46:01
|
Hi All! Thanks Zoltan we have: http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-1.diff.bz2 This patch is against -mm linux tree . For me AT PS/2 keyboard will not work. fbcon is not implemented. PCI hack is not included. Aivils Stoss |
|
From: James S. <jsi...@ww...> - 2005-02-21 21:55:46
|
> as large console cleanups went into the -mm tree and those cleanups > are also part of the Ruby tree, I thought I look at the Ruby tree > and port it to 2.6.11-rc4 + the following 4 patches: Yeap. I talked to Andrew Morton and Christoph Hellwig about the patches. The major difference is that struct vt_struct is removed completely. Chris told me we can add in struct vt_struct again at a later time. Well he actually ask me to rename it to something else. The big patch which is really nice is the killing off of the console macros. This is a good thing that I never got around to doing. > 1. cleanup-vc-array-access.patch > 2. remove-console_macrosh.patch > 3. merge-vt_struct-into-vc_data.patch > 4. merge-vt_struct-into-vc_data-fix.patch As for merging the ruby tree. I would suggest we wait until after the summer OSL conference. The reason beinging is that alot of rework is going into the fbdev/drm layer. I have ask Jon Smirl to help him with the demo at the OSL conference on the next generation X server. The next generation X server will be based totally on top of OpenGL using drm/fbdev. I'm going to be working with him to make sure that it supported full multihead support!!!!! We will not have to do anymore X server hacks. All the X Server hack on the PCI bus will go away. So we have alot of work ahead. I say by next year this time main stream linux will be multi-desktop ready. |
|
From: Benjamin H. <be...@ke...> - 2005-02-22 07:30:29
|
> The next generation X server will be based totally on top of OpenGL using > drm/fbdev. I'm going to be working with him to make sure that it supported > full multihead support!!!!! We will not have to do anymore X server hacks. > All the X Server hack on the PCI bus will go away. So we have alot of work > ahead. I say by next year this time main stream linux will be > multi-desktop ready. In fact, DRM handles hardware access arbitration. Wether it's 3D/GL/whatever depends on what userland client library is used. For "legacy" cards, we can perfectly have a 2D driver using DRM to submit commands (or beeing allowed to mmap the registers the good old way eventually) and a server built on top of this (hint hint: kdrive ? :) The main ideas is to have a common mode setting and hw access arbitration (& command submiting, DMA/AGP management etc...) infrastructure that isn't in the server. Wether you then use a 2D userland driver, a 3D userland driver, XGL on top of the later, or whatever else is pretty much irrelevant. I may want to rework a bit of the fbdev mode setting API if I can find time to work on this. It needs some better ways to determine "related" framebuffers, trigger re-probe of outputs, play with the output mapping, and get hotplug events to userland. It also need to properly work with the DRM for access arbitration to the HW. There are a lot of issues to deal with before we can safely change modes on the fly while a 3D server is running, but we'll have to be capable of it ultimately. Ben. |
|
From: Helge H. <hel...@ai...> - 2005-02-22 10:50:07
|
James Simmons wrote: >As for merging the ruby tree. I would suggest we wait until after the >summer OSL conference. The reason beinging is that alot of rework is going >into the fbdev/drm layer. I have ask Jon Smirl to help him with the demo >at the OSL conference on the next generation X server. > > How about getting some bits and pieces in, so as to keep the ruby patch smaller? There could be stuff that isn't "dangerous", perhaps not enough to run multiple consoles but a few step in that direction? >The next generation X server will be based totally on top of OpenGL using >drm/fbdev. I'm going to be working with him to make sure that it supported >full multihead support!!!!! We will not have to do anymore X server hacks. >All the X Server hack on the PCI bus will go away. > Now that will be really nice. :-) No more "mostly works, just don't do resolution changes / console switches when another user is active", and no more worrying about the order of starting (or restarting) xservers. I like to have X restart on logout - that tends to free up memory. >So we have alot of work >ahead. I say by next year this time main stream linux will be >multi-desktop ready. > > Great! Helge Hafting |
|
From: James S. <jsi...@ww...> - 2005-02-22 17:19:33
|
> >As for merging the ruby tree. I would suggest we wait until after the > >summer OSL conference. The reason beinging is that alot of rework is going > >into the fbdev/drm layer. I have ask Jon Smirl to help him with the demo > >at the OSL conference on the next generation X server. > > > > > How about getting some bits and pieces in, so as to keep the ruby patch > smaller? There could be stuff that isn't "dangerous", perhaps not enough > to run multiple consoles but a few step in that direction? There is so much to do and no time to do it. Last night in my fustration I realized the only way we are going to get anywhere is have people working on this projects for a living. So I'm going to commericalize ruby and sell it. This working on it 2 hours a week is going to get us no where. We need cash flow so people can work on this project. I noticed this with the fbdev project as well. We just dont have any real man power. I have in the past asked for support from different sources. No one was willing to help :-( |
|
From: Aivils <ai...@un...> - 2005-03-01 11:47:00
|
Hi Zoltan! Now we have linux-ruby against mm. What comes next? http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-3.diff.bz2 Aivils Stoss |
|
From: Zoltan B. <zb...@fr...> - 2005-03-01 19:03:43
|
Aivils =EDrta: > Hi Zoltan! >=20 > Now we have linux-ruby against mm. What comes next? > http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-3.diff.bz2 >=20 > Aivils Stoss Hm. In vty_init(), we disabled this with "#if 0": #ifdef CONFIG_MDA_CONSOLE mda_console_init(); #endif We should port the mdacon to Ruby, too. Maybe someone with an old machine with both VGA and MDA, can help us with testing. I have neither an one, nor an ISA slot.. And Linux supports other architectures beside ix86 and x86-64, we ask for help from the different arch maintainers, so we can or they will port the arch-specific parts. But in this state, we can start the discussion with the kernel maintainers. Andrew Morton will have a few kind words for us, I think. I don't know what backwards compatibility we lose with the Ruby patch. Think about configuring both vgacon and mdacon into the old kernel. What vtXX will mdacon use? Is there any software that use it for display-only mode? Will they work on ruby kernel with only one keyboard, too, unmodified? And recently Antonio Daplas modified the fbdev/fbcon subsystems, we must talk to him as well so we don't step on each other's toes. The X people will be interested, too. Finally they may accept your PCI isolation patch, preferably in unconditional mode, e.g. no keyword needed to have separated X servers working together peacefully. I think that's all for now. I think we have to get the ruby patch into the -mm tree, the sooner, the better. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Jeremy G. <j....@lo...> - 2005-03-02 01:06:50
|
On Tue, 2005-03-01 at 13:47 +0200, Aivils wrote: > Hi Zoltan! > > Now we have linux-ruby against mm. What comes next? > http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-3.diff.bz2 > > Aivils Stoss ck-sources ? -Jeremy |
×
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