DST/BT878 module customization (.. was: Critical points about ...)

[Markus Rechberger]

Hi,

Trent Piepho wrote another patch for it, it just completes Uwe's patch
in the end.

http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb

as far as I see from that patch it cleans up a memory leak which would
happen when the system tries to load the dst module if it's not
available and it also prints a message that points the user should
enable it in the kernel if needed.

It also bundles the dst and dst_ca objects to one selectable option.
So the idea remains the same.
> From my side I do not see any problem with that patch, if someone else
has a problem with it please state out the reason.

Markus


On 4/30/07, Markus Rechberger <mrechberger@xxxxxxxxx> wrote:
> On 4/30/07, Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx> wrote:
> >
> > On Apr 30 2007 19:25, Uwe Bugla wrote:
> >
> > >THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN
> THAT
> > DST
> > >AND DST_CA ARE NOT NEEDED AT ALL!!!!
> > >[...]
> >
> >
> > How much on the Theo-meter are we yet?
> >
>
> it's enough, I told him that I'll look at it and try to get some other
> people involved if it really breaks something it should get stated
> out; and I'll refuse any further help if he starts to write any more
> abusive mail.
>
> So to his proposal:
>
> the whole noise is about following Makefile patch:
> -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o
> +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o
> +obj-$(CONFIG_DVB_DST) += dst.o
> +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o
>
> that symbol_request is unable to return a valid pointer if DST an
> DST_CA aren't selected should be ok because this would only happen if
> someone didn't compile them in (an appropriate error message should be
> added for that)
>
> I'm trying to look closer at this issue with some other developers, if
> it's really that easy to split off the dst module from the bt* objects
> without breaking anything, to me the direction this patch goes seems
> to be ok, some people stated out that there are problems so I'll try
> to get more information about that.
>
> Markus


--
Markus Rechberger
-
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/