I'm not sure how to respond to this. As a long time linux user I still *think* most linux users/admins (most are both :)) read the manual (or well part of it) or at least have some form of understanding. More people are coming over to this side tho' and more and more of them follow howto's without thinking/investigating themselves, often dated or written for other distributions (mostly not a problem, but some times is). So, at one side I'd like to say yes, on the other hand, I still feel discomfort when some distro has set "alias rm='rm -i'" for example in order to protect me. Probably not a very good analogy, but I can just unalias rm and do it like that or answer yes, without having to go through to the code. In those lines of thoughts, I would prefer something along the lines of WARNING, we don't think this is wise this is a type <x> device!, are you sure you want to do this and be smart-ass?! kind of q than plain blocking of it all together :). I'm still not a dev btw and can't say I have searched thoroughly, but isn't TYPE_DISK something from rtslib? Doesn't seem like a kernel thing to me, but I'm no authority on that whatsoever. If it were however, I would assume the code would have checked this type with the kernel, instead of comparing major numbers against a list, where the list is part of the rtslib code, not the kernel sources/headers. Every time a block device (more accurate major number for a block device) gets added to the kernel now, the list in rtslib would have to be updated. Reasons above aside, I think that will involve quite some maintenance and who's actively going to monitor new major numbers just to update this? Even more complex, what will happen with code like zfsonlinux.org? I'm not sure those kind of projects communicate major numbers with the mainline kernel or just pick one that's free (possibly resulting in different projects using the same major number but one is block and another something entirely differently). Thanks for the re' On 11-07-12 02:03, Andy Grover wrote: > On 07/09/2012 11:00 PM, Christoph Hellwig wrote: >> On Mon, Jul 09, 2012 at 11:46:08AM -0700, Andy Grover wrote: >>> It looks like it only wants to allow the use of TYPE_DISK block devices >>> for iblock. Is there another way from userspace to know if a block >>> device is a disk vs. tape or optical? >> iblock should not care - it just submits bios. And pscsci already does >> it's own internal checks. > I am doubtful iblock works with non-disk block devices. It assumes > TYPE_DISK. > > We should try to warn people when defining a backstore, not errors to > dmesg when they actually try to use it. The major number check may be > ugly and/or wrong, but if there are no alternatives for how we can guide > people to prefer pscsi over iblock for non-disk scsi devices, isn't it > better than nothing? > > Regards -- Andy -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
