On Wed, 25 Jan 2012, Daniel Taylor wrote: > I handled this a bit differently, for our old 2.6.32 kernel, based on > discussions on this list with Matthew Dharm back in April 2011. > > I changed the scsi_level entry in /sys to be read/write, rather than > read-only. This allows a ussr-space white-list handler to fixup > drives that are known to work. > > The gist of the discussion was whether the kernel should keep a white > or black list for every drive on the planet to handle the scsi_level > change/no-change or that user space could have the database and either > apply it manually or automatically through udevd. Matthew expressed > a preference for user space to manage the information. > > I can't find the patch set for these flag changes in my local email > archive, but can we have controls for these available in user-space? Is this really workable in practice? The scsi_level value is used when scanning for LUNs and partitions, which doesn't give userspace much time to change the value. Can you explain the reason why you need to change the scsi_level value? Alan Stern -- 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