On Tue, Apr 8, 2014 at 8:56 AM, Antti Palosaari <crope@xxxxxx> wrote: > On 08.04.2014 15:43, Mauro Carvalho Chehab wrote: >> Em Mon, 07 Apr 2014 20:32:19 -0700 >> "Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxx> escreveu: >>> >>> Commit bcf43393 as of linux-next next-20140320 added this Makefile >>> header extension: >>> >>> ccflags-y += -I$(srctree)/drivers/staging/media/rtl2832u_sdr >>> >>> This ends up calling a staging exported symbol rtl2832_sdr_attach(). >>> Let's not pollute driver code with staging code or dependencies. >>> >>> Folks, can this be cleaned up? This sets a precedent for doing more >>> of this, and this can get hairy. Its also not fair for folks who >>> don't want to carry over any staging code. This forces them to, and >>> its not just a header file, its a full exported symbol. What about >>> synchronization with differen trees? Was this addressed with Greg? <-- snip --> >> The SDR code is at staging not because it has low quality, but because >> we're still testing the SDR API before setting it into a stone. I see, so there is no guarantee to userspace on API if the kernel moves up? Its an interesting usage case for staging, perhaps one of the better ones :) >> Antti, please correct if I'm wrong, but the rtl2832u_tuner_attach() >> code seems to not expect that the attach code succeeds. So, the only thing >> that will happen DVB_RTL2832_SDR is disabled is that warning saying that >> SDR is disabled will be sent to dmesg. > > That is what happen and IIRC I tested it too once. I wasn't concerned over compilation but rather setting the precedent of non staging code depending on staging headers, if this wasn't done already. >> So, I don't see why to disable the entire driver due to that. Instead, >> Just revert changeset bcf43393579e at the backport trees should be enough, >> if don't want to backport the SDR driver. > > > I will look if I can make mainline rtl28xxu driver compile without a staging > directory (as that new SDR extension is on staging directory currently). That'd be swell! While this is one of the best use cases for staging I am just concerned over abuse over it. Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
