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

[Bernie Thompson]

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.

Bernie

On Tue, Nov 17, 2009 at 7:42 AM, Greg KH <greg at kroah.com> wrote:
> On Tue, Nov 17, 2009 at 09:22:27AM +0100, Roberto De Ioris wrote:
>> Greg, the use of int instead of __u32 is my fault, i will cut one of my
>> finger ASAP :P
>
> Heh, no problem.  How about instead of that, you add the needed
> compat_32 interface for the ioctl?  Although that might be just as
> painful in the end...
>
> thanks,
>
> greg k-h
>