lkml.org 
[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Loop devices under NTFS
Adam J. Richter wrote:

>On Wed, 28 Aug 2002 at 00:59:55AM +0100, Christoph Hellwig wrote:
>
>
>>On Tue, Aug 27, 2002 at 04:42:56PM -0700, Adam J. Richter wrote:
>>
>>
>>>>On Tue, Aug 27, 2002 at 06:53:19AM -0700, Adam J. Richter wrote:
>>>>
>>>>
>>>>> Why?
>>>>>
>>>>> According to linux-2.5.31/Documentation/Locking,
>>>>>"->prepare_write(), ->commit_write(), ->sync_page() and ->readpage()
>>>>>may be called from the request handler (/dev/loop)."
>>>>>
>>>>>
>>>>Just because it's present in current code it doesn't mean it's right.
>>>>Calling aops directly from generic code is a layering violation and
>>>>it will not survive 2.5.
>>>>
>>>>
>>> Only according your own proclamation. You are arguing
>>>circular logic, and I am aruging a concrete benefit: we can avoid an
>>>extra copying of all data in the input and output paths going through
>>>an encrypted device.
>>>
I'me new to kernel development and i've never fooled around with drivers
before (I do have a course in it this september though, Wohoo!).

Why are you saying it would copy the data? Couldn't you just make some
sort of shared memory system that would let you unencript/uncompress the
data without having to do a copy? The way i see it you can read the
block, pass it through the necessary mods using the same data. You
could get a wierd race condition if your uncompress and your unencript
work on the same data at the same time but that can easily be avoided
The way i see it, the NTFS driver should be able to read the file and
uncompress. The loop driver should have access to that block without
having to do a copy to present it to a third party driver. Which then
reads the data read by the driver and rpesents it as a filesystem.

Maby even do away with loop.c, there should really be no loop.c . A
normal mount (/dev/hda1 for example) is a first level mount. If you let
/mnt/foo/myfile.iso be from /dev/hda1, then the chain should be
/dev/hda1->ISO9660 module-->presentation.

I think the filesystem drivers should be written in such a way that they
are totally pluggable with eachother. That it doesn't matter where the
blocks are comming from and going to. You could have a mount of
/dev/hda1 of an iso containing an ext2 image within it etc etc etc.

But like i said i'me new to kernel development so I think i might have
the wrong perspective.


-----------------------------------
Andre Bonin
Student in Software Engineering
Lakehad University
Thunder Bay,
Canada
-----------------------------------

>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.044 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site