[Libdlo] [PATCH 2.6.32-rc7 1/1] udlfb: add dynamic modeset support

Greg KH greg at kroah.com
Tue Nov 17 11:37:42 PST 2009


On Tue, Nov 17, 2009 at 11:24:44AM -0800, Bernie Thompson wrote:
> I already chopped off all my fingers long ago, so I have none to offer ...
> 
> Udlfb made it into kernel staging shortly after it was created, with
> issues (e.g. ints in ioctls, synchronization, etc.). It then has
> received few updates in recent months -- most day-to-day users went to
> displaylink-mod (dynamic modeset is an essential feature).  This is a
> bad situation, as the user and developer communities' attention is
> split.
> 
> This patch started out with the idea of merging the changes that
> Roberto went on to do under displaylink-mod, back into his original
> udlfb. Then we could then look at merging in good things from Jaya's
> driver, then start doing actual new work on the many problems and
> todos ...
> 
> But everything starts with a first step.
> 
> This patch has already headed down the slippery slope of
> rewriting-during-merging.  It's doable to slide a little further down
> the slope for potentially impactful new things coming into udlfb (like
> mutex or refcounting errors) by fixing or removing those parts.
> 
> But attempting, in this one patch, to also fix a wider set existing
> udlfb issues (e.g. ioctl handling, which has dependencies on the X
> server; or any of the many other issues with the existing codebase
> that aren't at kernel standards) would mean a patch of a more
> expansive nature. In that case, this patch wasn't created with the
> appropriate mindset, and should be abandoned.
> 
> So is this patch worth working through, given its nature? Or should we
> look for someone to take a different approach? I don't want to create
> confusion by doing more here, unless it's likely to work out and be
> something we can build on.

It is worth working through, but please, I can not add obviously buggy
and incorrect changes to the kernel tree.  To do so would be crazy,
right?

The ioctl thing I can overlook for now, but not the locking bugs, that's
just waiting for a bug report from a user to have happen.

thanks,

greg k-h


More information about the Libdlo mailing list