Re: [PATCH 1/7] Adding empia base driver

[Greg KH]

On Thu, Oct 23, 2008 at 12:35:54AM +0200, Markus Rechberger wrote:
> On Thu, Oct 23, 2008 at 12:27 AM, Greg KH <greg@xxxxxxxxx> wrote:
> > On Thu, Oct 23, 2008 at 12:24:31AM +0200, Markus Rechberger wrote:
> >> On Thu, Oct 23, 2008 at 12:09 AM, Greg KH <greg@xxxxxxxxx> wrote:
> >> > On Wed, Oct 22, 2008 at 11:14:36PM +0200, Markus Rechberger wrote:
> >> >>     em2880-dvb:
> >> >>     * supporting the digital part of Empia based devices, which
> >> >> includes ATSC, ISDB-T and DVB-T
> >> >
> >> > <snip>
> >> >
> >> > Doesn't this driver duplicate some of the existing devices we already
> >> > support with the current in-kernel driver?  If so, why not just add the
> >> > new device support to the existing driver instead of duplicating
> >> > everything?
> >> >
> >> > This is going to cause a big problem for distros as they will not know
> >> > which to enable, so they will probably just disable this one, which is
> >> > what I don't think you want to have happen :(
> >> >
> >>
> >> the current driver doesn't support most devices which are in there,
> >
> > Then why not just add new device support to the existing one?
> >
> >> also the alsa audio driver can easily crash the whole system. (It's my
> >> code so I know what was wrong there).
> >
> > Why not send patches to fix it?
> >
> 
> that's why I'm sending that request at the moment, development still goes on
> on my side.

I don't understand, I don't see patches here to fix the existing
problems in the existing driver.  Am I missing something?

> >> Very likely the best would be to replace the available driver with it
> >> but I don't care, alot people use and have been using the driver from
> >> mcentral.de for a long time, development has always been opensource
> >> there too.
> >
> > Dropping existing code and replacing it entirely with a new base is not
> > how Linux kernel development works for the most part.
> >
> 
> the patch adds the driver from mcentral.de as alternative entry, not
> the best way but it currently supports almost all devices which have
> an entry in there.

What do you mean by "alternative" entry?  Our device/driver matching
system doesn't allow for "alternates" it is a "first one there wins"
type system, which, while isn't the nicest, is what it is.  This driver
is going to cause problems for distros, and for users, as if you build
them both as modules, it is pseudo-random which one will end up being
loaded first and binding to the device.

Which is not something we generally want to do to our users at all.

> > How about just sending patches in an incremental way, fixing problems in
> > the current driver that you know about, and adding support for all of
> > this goodness as well?  That's what all 2000+ other kernel developers
> > do when they want to make changes like this.
> >
> 
> I understand what you mean although too many things went from from the
> beginning on and people were in general not participating at
> discussions, it slightly changed now but the codebase evolved over
> time.
> 
> I'll be happy to do so for upcoming patches.

So we should drop our current rules for you, and trust that things from
here on out will be correct?  That doesn't sound like a good idea for us
to do, would you recommend doing something like that for someone else?

Especially given the above mentioned problems for users, this really
isn't going to work out.

Please send patches that evolve the current drivers into supporting
these new devices so that our development model is followed, and no user
ends up in trouble.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/