On Thu, 26 Apr 2007, James Bottomley wrote: > Personally, I don't like to see 2.4 and 2.6 in a new driver, and > will tend to try to force it to be 2.6 only. For an existing > driver, I tend to be much more tolerant: removing the huge gobs of > code to achieve 2.6 only is usually a bit disruptive on both the > driver and the maintainer > > > But if a driver is no longer actually maintained for both kernels > > these checks become useless (and there quickly arised > > unconditional 2.6-only code in such a driver) and can be removed. > > This driver is maintained by > > Yokota Hiroshi <yokota@xxxxxxxxxxxxxxxxxxxxxxx> > GOTO Masanori <gotom@xxxxxxxxxx> > > As it says in the header. It was last modified in May 2006, so it > is maintained under the somewhat elastic standards of SCSI. I've > cc'd them to see what they think. while we're on the subject, what's the policy on supporting kernel version selection *within* the 2.5 series? as in: $ grep -r "KERNEL_VERSION(2,5" * drivers/scsi/pcmcia/nsp_cs.h:#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,74)) drivers/scsi/pcmcia/nsp_cs.c:#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)) drivers/scsi/pcmcia/nsp_cs.c:#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,5,2)) drivers/scsi/pcmcia/nsp_cs.c:#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,5,73)) ... etc etc ... granted, this doesn't happen in a lot of files (almost of them SCSI-related), but is it official policy to support code based on its release number in the 2.5 series of releases? unless you have a good reason, wouldn't it make more sense to compare against (2,6,0) rather than, say, (2,5,73)? just an observation. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page ======================================================================== - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
