EXPORT_SYMBOL(fat_get_block)
in [Kernel]
|
Prev: [PATCH 6/8] ceph-rbd: osdc support for osd call and rollback operations
Next: [PATCH 5/8] ceph-rbd: refactor mount related functions, add helpers
From: David Cross on 13 Aug 2010 13:50 Hello Hirofumi, I would like to export this symbol from the vfat code and add this patch to the Linux kernel. You are listed as the MAINTAINER for FAT and VFAT. As such, I need your approval to do it. The reason that I need to export this symbol is to allow for file based DMA in which the file needs to be pre-allocated. The pre-allocated block addresses are passed to a DMA engine which then directly transfers the data to non-volatile storage. Please let me know if you have any objections to exporting this symbol or if you need additional information from me concerning this change request. I am happy to answer any questions that you may have about this in the meantime. Thanks, David Cross --------------------------------------------------------------- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. --------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 13 Aug 2010 14:00 On Fri, Aug 13, 2010 at 10:45:39AM -0700, David Cross wrote: > Hello Hirofumi, > I would like to export this symbol from the vfat code and add this patch > to the Linux kernel. You are listed as the MAINTAINER for FAT and VFAT. > As such, I need your approval to do it. > The reason that I need to export this symbol is to allow for file based > DMA in which the file needs to be pre-allocated. The pre-allocated block > addresses are passed to a DMA engine which then directly transfers the > data to non-volatile storage. Also, why do this at the FAT level, and not more correctly at the block layer level? What happens if this isn't a FAT partition on the device? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Cross on 13 Aug 2010 14:50 On Fri, 2010-08-13 at 10:54 -0700, Greg KH wrote: > On Fri, Aug 13, 2010 at 10:45:39AM -0700, David Cross wrote: > > Hello Hirofumi, > > I would like to export this symbol from the vfat code and add this patch > > to the Linux kernel. You are listed as the MAINTAINER for FAT and VFAT. > > As such, I need your approval to do it. > > The reason that I need to export this symbol is to allow for file based > > DMA in which the file needs to be pre-allocated. The pre-allocated block > > addresses are passed to a DMA engine which then directly transfers the > > data to non-volatile storage. > > Please let me know if you have any objections to exporting this symbol > > or if you need additional information from me concerning this change > > request. I am happy to answer any questions that you may have about this > > in the meantime. > > Wait, _I_ have an objection to exporting this symbol. > > I really don't think it is needed at this point in time, as we really > need to figure out exactly what your driver is doing to want to need to > call this function. OK, I am trying to answer all questions on this topic that I am getting, but honestly I have not gotten a lot so far. > So please, let's not export it for now, when we get to the point that we > all agree that this driver is doing the "correct" thing, then we can > export the symbol, ok? Sure, I think that the driver is doing the correct thing, but that is mostly because I have not found another way to solve this issue. If there is a different, correct way I am happy to implement it. > thanks, >Also, why do this at the FAT level, and not more correctly at the block > layer level? The short answer is that the block level does not have the file system awareness needed to determine where a file should be stored on the NVM device. The longer answer is to consider the case of an MTP host, which operates at the file level. It sends the mobile (Linux) device "SendObject" which tells it to store the file on its file system. When the device receives this, it has two options: 1) receive all data, buffer it, then write the file. This is typically a slow process USB->Processor->SDRAM->Processor/DMA engine->Media 2) pre-allocate the file as soon as it knows that it is coming and how big it is, and then send the block addresses to an external DMA engine and let it transfer the data from the MTP host directly The West Bridge driver goes for option two for performance reasons. In doing this, it needs to get information from the file system on where to store the file. >What happens if this isn't a FAT partition on the >device? Good question. So far, it has been stored on a FAT partition in most use cases because the user typically wants the option to enumerate the device as mass storage as well or be able to see content on a PC if the SD card is removed. However, there is no reason that this could not be done with ext2 or other filesystems on non-removable media. This would require some work to figure out how to implement a pre-allocation interface with it. Alternatively a more general pre-allocation interface could be added (falloc()) to implemented file systems to make this process easier. Please let me know if there are any additional questions or implementation feedback on this. Thanks, David --------------------------------------------------------------- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. --------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 13 Aug 2010 15:00 On Fri, Aug 13, 2010 at 11:43:12AM -0700, David Cross wrote: > OK, I am trying to answer all questions on this topic that I am getting, > but honestly I have not gotten a lot so far. Seriously, I think there is absolutely no point in even arguing this. A driver has absolutely no business looking into any filesystem layout. > 1) receive all data, buffer it, then write the file. This is typically a > slow process USB->Processor->SDRAM->Processor/DMA engine->Media > 2) pre-allocate the file as soon as it knows that it is coming and how > big it is, and then send the block addresses to an external DMA engine > and let it transfer the data from the MTP host directly > > The West Bridge driver goes for option two for performance reasons. In > doing this, it needs to get information from the file system on where to > store the file. And what if someone else changes the layout undernath you? Or uses a different filesystem? Basically you will have to introduce operations to the VFS to lock down a file against layout changes and do DMA transfers. It's fine if you only implement it for fat in the beginning, and just return an error for others, although in general the implementation would be easily extendable to other filesystems using generic code and the get_blocks callbacks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 13 Aug 2010 15:10
On Fri, Aug 13, 2010 at 11:43:12AM -0700, David Cross wrote: > On Fri, 2010-08-13 at 10:54 -0700, Greg KH wrote: > > On Fri, Aug 13, 2010 at 10:45:39AM -0700, David Cross wrote: > > > Hello Hirofumi, > > > I would like to export this symbol from the vfat code and add this patch > > > to the Linux kernel. You are listed as the MAINTAINER for FAT and VFAT. > > > As such, I need your approval to do it. > > > The reason that I need to export this symbol is to allow for file based > > > DMA in which the file needs to be pre-allocated. The pre-allocated block > > > addresses are passed to a DMA engine which then directly transfers the > > > data to non-volatile storage. > > > Please let me know if you have any objections to exporting this symbol > > > or if you need additional information from me concerning this change > > > request. I am happy to answer any questions that you may have about this > > > in the meantime. > > > > Wait, _I_ have an objection to exporting this symbol. > > > > I really don't think it is needed at this point in time, as we really > > need to figure out exactly what your driver is doing to want to need to > > call this function. > > OK, I am trying to answer all questions on this topic that I am getting, > but honestly I have not gotten a lot so far. That's because not many people have noticed the code yet :) > > So please, let's not export it for now, when we get to the point that we > > all agree that this driver is doing the "correct" thing, then we can > > export the symbol, ok? > > Sure, I think that the driver is doing the correct thing, but that is > mostly because I have not found another way to solve this issue. What specifically is the issue here that you are trying to solve? And why has no other driver ever needed this type of functionality before? > > thanks, > > >Also, why do this at the FAT level, and not more correctly at the block > > layer level? > The short answer is that the block level does not have the file system > awareness needed to determine where a file should be stored on the NVM > device. > The longer answer is to consider the case of an MTP host, which operates > at the file level. It sends the mobile (Linux) device "SendObject" which > tells it to store the file on its file system. When the device receives > this, it has two options: > 1) receive all data, buffer it, then write the file. This is typically a > slow process USB->Processor->SDRAM->Processor/DMA engine->Media > 2) pre-allocate the file as soon as it knows that it is coming and how > big it is, and then send the block addresses to an external DMA engine > and let it transfer the data from the MTP host directly We have a userspace MTP driver for Linux, using gadgetfs, right? So none of this is applicable from what I can tell. > The West Bridge driver goes for option two for performance reasons. In > doing this, it needs to get information from the file system on where to > store the file. Look at how Linux already handles MTP for how to handle this properly, I don't think there is any need to do any of this from within the kernel. > >What happens if this isn't a FAT partition on the >device? > Good question. So far, it has been stored on a FAT partition in most use > cases because the user typically wants the option to enumerate the > device as mass storage as well or be able to see content on a PC if the > SD card is removed. However, there is no reason that this could not be > done with ext2 or other filesystems on non-removable media. Like NTFS? How are you going to handle that when you run out of size due to the limitations of FAT? Hint, that's not going to work with this type of solution... > This would require some work to figure out how to implement a > pre-allocation interface with it. Alternatively a more general > pre-allocation interface could be added (falloc()) to implemented file > systems to make this process easier. Userspace handles this quite easily already, see above. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |