|
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
|