On Fri, 2004-09-03 at 23:04, Jon Smirl wrote: > We're going to have to work out a GPL/BSD solution for the fbdev > merge. There are 80,000 lines of code in the fbdev directory. It is > impractical to rewrite them. It's probably also impractical to > relicense the fbdev code BSD since we would have to locate all of the > coders. > > The proprietary drivers are ok. They don't have to use the GPL > DRM/fbdev code; nothing stops them from writing their own version. I > also don't see how a binary driver that links with drm_core and the > kernel is any different than one that just links to the kernel. GPL > will stop a vendor from taking the source for drm_core/lib and making > a private version. But we want to stop that. > > So what do we do about FreeBSD? For example I need to bring in the I2C > and mode setting code from the GPL fbdev radeon driver into the DRM > one. I don't want to rewrite a 1,000 lines of working driver code. > > How many DRM users are there on FreeBSD? I've only run into three that > I know of. I'm sure there are more but is it 1,000 people or 100,000? > I don't think DRM CVS will even compile currently on FreeBSD. I think > I broke it a week ago and no one has said anything. > > Would this work? drm/shared and drm/bsd directories are BSD licensed. > drm/linux is GPL licensed. Any fbdev code I add will go into > drm/linux. Then we patch up drm/bsd so that is continues to work given > the changes in drm/linux. The other alternative is simply forking the > tree. The licenses also allow chunks of DRM to be pulled into the > fbdev directory but that's effectively a fork. > > The code is starting to drift further from BSD anyway. BSD is missing > major OS features like hotplug and resource control that Linux DRM is > starting to use.
You mean all the rearchitecting you've been doing to make the driver behave like it actually attaches to specific device? Yeah, BSD has wanted that since the very beginning. I just never implemented it because I didn't want to make more diffs compared to Linux. As far as hotplug, well, I've never used that feature on Linux and haven't looked in to it. When I think of "hotplug" I don't see anything that couldn't be implemented using FreeBSD's current driver model with only minor changes. I personally think that these major architectural changes you're looking at doing would be best done outside of our stable DRM (head) branch in DRI CVS. I'm not expecting FreeBSD to adopt them, because our requirements are different (debugging of panics is supposed to be done over serial console or through dumps. We don't generally have an fbdev equivalent, and though some individuals have produced mostly-complete fb devices, nobody has really been interested). If it gets to the point that Linux wants to move to the fb-ified DRM and it's going to become the stable version, I would say let's deal with those issues then. Or just stick your GPL code in drm/linux and not worry about BSD, if it can be developed in head without disrupting (Linux) users. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
