lkml.org 
[lkml]   [2010]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: EXPORT_SYMBOL(fat_get_block)
    From
    Date
    On Fri, 2010-08-13 at 14:50 -0400, Christoph Hellwig wrote:
    > 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.
    I think you misunderstand, the driver is not looking into the file
    system layout. The driver is requesting that the file system allocate a
    file and tell it where it allocated it to. This is the reason for the
    fat_get_block call.
    >
    > > 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?
    I am not sure I understand the question. The point of making the call
    into the filesytem rather than reading sectors and "looking into the
    file system layout" is to make sure that the filesystem is the arbiter
    of all storage requests. How would someone change the layout underneath
    me?

    > Or uses
    > a different filesystem?
    That is a good question, I think it is the same one that Greg KH had. To
    restate the answer in the last email, I don't know how to handle this
    case. I am sure that it is possible to develop a method to pre-allocate
    using other filesystems, but I have not looked into it yet as the driver
    was developed for systems which have removable storage. Removable
    storage needs to work with card readers, as such it uses FAT.

    > 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.
    So, your basic concern is whether or not someone else tries to write to
    the same file while the transfer is ongoing, correct? I understand the
    implementation idea you are proposing to get around this issue, but it
    seems that the simplest solution is to punt to the application handling
    the transfer (ie don't access the pre-allocated file until you know the
    transfer is complete). This is the basic idea of how it has been done in
    previous implementations, so I am not sure why this is not a potential
    solution in this case.

    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.
    ---------------------------------------------------------------



    \
     
     \ /
      Last update: 2010-08-13 21:09    [W:0.027 / U:0.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site