On Tue, 2011-11-29 at 16:57 -0800, Andy Grover wrote: > On 11/29/2011 12:15 PM, Jörn Engel wrote: > > On Tue, 29 November 2011 10:00:18 -0800, Andy Grover wrote: > >> On 11/24/2011 01:03 AM, Christoph Hellwig wrote: > >>> If you use a block device use iblock - it's generall going to be a lot > >>> faster and more efficient. If you want to use regular files use the > >>> file backend. That naming should make it kinda obvious, except for the > >>> weird "i" in iblock that still keeps confusing me. > >> > >> What does the "i" in iblock mean? > >> > >> Would you take a patch to just call it "block"? > > The name came originally from the IDE/ATA maintainer believe it or not.. > > I believe a number of people might object. There is userspace code > > that expects processes to be called LIO_iblock, not LIO_block, etc. > > You would need a _very_ strong argument to break these. Solving world > > hunger or prevent a nuclear meltdown I would accept. Aesthetics - not > > so much. > > What userspace code depends on the name of the transport processing > thread?? This is a really bad example of a userspace dependency. > > But you are correct that there *are* configfs interfaces that are named, > based on the backstore name. However, I still view the situation as > "still early" enough so that if we want to spare our users the confusion > of why the backstore is named iblock instead of block for the rest of > eternity, then maybe we should do that while we REALLY still can. > Changing this without some type of configfs symlink on the kernel side is going to get my NACK for the immediate future. Let's please not break backend configfs usage for simply symbolic naming reasons. Out of kernel-land, allowing 'block' to be referenced as a python object along 'iblock' in rtslib code would be a useful option for python level coders. (jxm CC'ed) Thanks, --nab -- 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
