On Mon, Jan 10, 2011 at 10:01:03PM +0000, R.M. Thomas wrote: > Greg KH wrote: > >>-# Impose all or none of the following: > >> ccflags-y += -DEASYCAP_IS_VIDEODEV_CLIENT > >> ccflags-y += -DEASYCAP_NEEDS_V4L2_DEVICE_H > >> ccflags-y += -DEASYCAP_NEEDS_V4L2_FOPS > >> ccflags-y += -DEASYCAP_NEEDS_UNLOCKED_IOCTL > >>+ccflags-y += -DEASYCAP_NEEDS_ALSA > >>+ccflags-y += -DEASYCAP_NEEDS_CARD_CREATE > > > >Don't add new flags that are always set. That just causes #ifdefs in > >the other files that also never get unused, so just remove them. > > > >In the end, all of these need to be removed anyway, right? > > The purpose of these flags is to allow me to keep the source code at > drivers/staging identical to the source code which is distributed in > the tarball downloadable from SourceForge. Merely by changing the > compiler flags a successful (i.e. warning-free) build can be achieved > on all kernels between 2.6.26 and 2.6.37 (inclusive), and moreover > the dependence on the V4L and ALSA subsystems can be turned on or > off at will. > > This has the obvious advantage of making things a bit easier for me, > but there is a more important reason for all these #ifdefs: a lot > more people are using the SourceForge version of the driver than are > testing the in-tree version. The driver has been in the kernel for > about six months, and during that time I have received precisely one > feedback report from somebody who has actually used the in-tree > driver (as opposed to people who have patched or commented on the > source code without using the driver to operate hardware). By > contrast, during the one-year life of the SourceForge project there > have been 557 contributions to the discussion forums, and many of > these have been very helpful to me in bringing to light programming > deficiencies which I had not detected myself. Arguably it would be > a pity if divergence between the in-tree driver and the out-of-tree > version led to a loss of the useful practical testing which the > SourceForge site allows. > > Having said all that, I am of course willing to sever the link > between the in-tree and out-of-tree drivers if you would prefer it > that way. Let me know what you think. The link should be severed as we can't move the driver out of the staging tree unless these types of things are removed. thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
