From: James S. <jsi...@ac...> - 2000-03-08 16:34:45
|
> > We should also patch the MAINTAINERS file, shouldn't we? > > Yes, but how we do that exactly will depend on how we do our release > packaging (which is James's problem). The best thing to do is place these patches in CVS and announce it on linux-kernel so people can go test it. Have CVS with 3 top directorys for each release. Sapphire, emrald, and ruby. Ruby is going to be the big on! Once we get feed back and any possible bug fixes we can send it off to linus. Perhapsa tree like this CVS -> shappire -> v2.0 -> v2.2 -> v2.3 -> emrald -> v2.0 -> v2.2 -> v2.3 -> ruby -> v2.3 -> v2.4 I have been working on fbdev today with a few new patchs. I going to see if I can sneak some time in to clean up the data struct stuff. Their are three data structs for the current console system. struct vt_struct; struct vc_data; struct vc; struct vt_struct is whats in tty->driver_data. Their is only some code relating to it in vt.c. Struct vc_data is everywhere for a video terminal system. I don't see it in any serial consoel code. It is a hardware independent data struct that represents the state of the video terminal device. The next data struct is vc which is this struct vc { struct vc_data *d; /* might add scrmem, vt_struct, kbd at some time, to have everything in one place - the disadvantage would be that vc_cons etc can no longer be static */ }; Which is really used anywhere. Just a few struct vc_data *conp = vc_cons[con].d; So it would look like using just vc_data and expanding it would be the best choose I think. Any opinons? "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 |