[MPlayer-matrox] mga_vid directions (was: insmod error)

[Ferdinand O. Tempel]

On Wed, 2005-03-09 at 09:50 +0100, Attila Kinali wrote:
> > - udev support
> 
> No clue how this works. I only found docu for users, no
> docu how to program for it.

Welp, after a short research session it seems that adding SysFS back in
is half the battle for getting udev running too, as udev uses the
information in sysfs (and hotplug events where appropriate) to construct
its device nodes. That's probably why you couldn't find much about it,
all the magic lies in correct information in sysfs and a little program
(udev) to interpret it.

> Missing here are:
> 
> * fix all race conditions (i know that there is at least one)
> * add spinlocks around all critical sections (mostly needed
>   for smp machines)
> * add more sanity checks

Scary advanced stuff. I'll leave that to a real developer :P

> > All of which aren't too hard to do. The first item is just cosmetic, but
> > to get anything included into the kernel it's very important. I'm not a
> > great C coder, but isn't a lot of the stuff which now is in mga_vid.c
> > supposed to reside in the mga_vid.h file? I mean the definitions,
> > macros, and all that...
> 
> I don't think so. Most of these defines are used only
> inside mga_vid.c and do not to be known outside.
> mga_vid.h is mainly a definition of the API for user space
> programs.

Makes sense.

> SysFS has to be done for inclusion as currently some configurations
> are done over the read/write interface of the driver, which isnt
> exactly nice.

Okay, so SysFS done properly has a bit of priority as it allows for
other stuff to happen too. Maybe it's as easy as adding back the sysfs
support which was already there, but maybe that's too simple. I won't be
able to play with this for two weeks (lacking the hardware, currently),
but since I was meaning to look at udev anyway, this seems like a good
excuse to actually do so.

> Go on! I'll gladly accept all patches that are clean and do what
> they are supposed to do. For an idea how a good patch should look
> like please read http://www.mplayerhq.hu/DOCS/tech/patches.txt.
> In contradiction to that file, i'll accept cosmetic changes,
> but if and only if they are separated from functional changes.

Yeah, I agree. I think it would be best to concentrate on function over
form right now, and clean up later. I'll try to follow the rules :-)

> > well...the choice is to keep seperate versions around, or again start
> > using #if's to cater to small changes. 
> 
> Nope, i'm not going to add #if's for older kernel versions.
> That just makes the code unmaintainable after some time.

Bah, annoying. This is one of the cases where de decisions made by
kernel developers make it harder for people to maintain out-of-tree
drivers. Even opensource ones. I wonder if they actually realized that.

> Ok, that code could be tarred and put somewhere as i consider it
> "stable" (though it isn't). Alternatively i can put up an svn/darcs
> server somewhere public and move mga_vid development there.
> But i really don't know what would be best.

I'll just send patches I have to here and let you handle the details.
Seems the easiest for now.

Ferdinand O. Tempel