Am Dienstag, den 05.02.2008, 16:38 +0100 schrieb
[EMAIL PROTECTED]:
> From: Heiko Carstens <[EMAIL PROTECTED]>
> Cc: Gerald Schaefer <[EMAIL PROTECTED]>
> Cc: Carsten Otte <[EMAIL PROTECTED]>
> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
> Signed-off-b
Am Dienstag, den 05.02.2008, 16:38 +0100 schrieb
[EMAIL PROTECTED]:
From: Heiko Carstens [EMAIL PROTECTED]
Cc: Gerald Schaefer [EMAIL PROTECTED]
Cc: Carsten Otte [EMAIL PROTECTED]
Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
Acked
Akinobu Mita wrote:
The use of get_zeroed_page() with __GFP_HIGHMEM is invalid.
Use alloc_page() with __GFP_ZERO instead of invalid get_zeroed_page().
*Ouch*
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
Akinobu Mita wrote:
The use of get_zeroed_page() with __GFP_HIGHMEM is invalid.
Use alloc_page() with __GFP_ZERO instead of invalid get_zeroed_page().
*Ouch*
Acked-by: Carsten Otte [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Avi Kivity wrote:
In the case of x86, we'll have 16 arch dependent files (i8259.[ch],
irq.[ch], lapic.c, mmu.c, paging_tmpl.[ch], svm.[ch], vmx.[ch],
x86.[ch], x86_emulate.[ch]) which warrant a kvm/ subdirectory IMO.
I think a subdirectory makes sense too. We'll end up with more than a
single
Avi Kivity wrote:
In the case of x86, we'll have 16 arch dependent files (i8259.[ch],
irq.[ch], lapic.c, mmu.c, paging_tmpl.[ch], svm.[ch], vmx.[ch],
x86.[ch], x86_emulate.[ch]) which warrant a kvm/ subdirectory IMO.
I think a subdirectory makes sense too. We'll end up with more than a
single
Jared Hulbert wrote:
I think so. The filemap_xip.c functionality doesn't work for Flash
memory yet. Flash memory doesn't have struct pages to back it up with
which this stuff depends on.
Struct page is not the major issue. The primary problem is writing to
the media (and I am not a flash
Jared Hulbert wrote:
I think so. The filemap_xip.c functionality doesn't work for Flash
memory yet. Flash memory doesn't have struct pages to back it up with
which this stuff depends on.
Struct page is not the major issue. The primary problem is writing to
the media (and I am not a flash
Nick Piggin wrote:
OK, thanks for taking a look at that. It will be helpful for testing
XIP with my new ramdisk driver (did you see the patch?).
I have'nt looked at it yet. I do appreciate it, I think it might
broaden the user-base of this feature which is up to now s390 only due
to the fact
ile
system in a very queer way.
After all, I don't see any risk in removing the check. The only driver
we have that does direct_access is drivers/s390/block/dcssblk.c, and
that one only supports block_size == PAGE_SIZE. I think the patch
should go into mainline.
Acked-by: Carsten Otte <[EMAIL PRO
Nick Piggin wrote:
Xip does only work, if both do match PAGE_SIZE because it
does'nt support multiple calls to direct_access in the get_xip_page
address space operation. Thus we check both here, actually this was
changed from how it looks after your patch as a bugfix where our
tester tried a
Nick Piggin wrote:
Xip does only work, if both do match PAGE_SIZE because it
does'nt support multiple calls to direct_access in the get_xip_page
address space operation. Thus we check both here, actually this was
changed from how it looks after your patch as a bugfix where our
tester tried a
in a very queer way.
After all, I don't see any risk in removing the check. The only driver
we have that does direct_access is drivers/s390/block/dcssblk.c, and
that one only supports block_size == PAGE_SIZE. I think the patch
should go into mainline.
Acked-by: Carsten Otte [EMAIL PROTECTED
Nick Piggin wrote:
OK, thanks for taking a look at that. It will be helpful for testing
XIP with my new ramdisk driver (did you see the patch?).
I have'nt looked at it yet. I do appreciate it, I think it might
broaden the user-base of this feature which is up to now s390 only due
to the fact
Nick Piggin wrote:
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb->s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/fs/ext2/super.c
Nick Piggin wrote:
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb-s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/fs/ext2/super.c
Avi Kivity wrote:
We intend to bind our virtio devices to PCI too, so that they look the
same in Linux userland across architectures.
Ouch.
That was my initial opinion too, but HPA has come up with a lean and
clean PCI binding for lguest. I think we should seriously consider
using that over
Avi Kivity wrote:
Unfortunately, we have to care for platform differences, subarch
differences (vmx/svm), hypervisor differences (with virtio), and guest
differences (Linux/Windows/pvLinux, 32/64). Much care is needed when
designing the ABI here.
Yea, I agree.
[actually thinking a bit, this
Avi Kivity wrote:
No, definitely not define a hypercall ABI. The feature bit should say
"this device understands a hypervisor-specific way of kicking. consult
your hypervisor manual and cpuid bits for further details. should you
not be satisfied with this method, port io is still
Avi Kivity wrote:
No, definitely not define a hypercall ABI. The feature bit should say
this device understands a hypervisor-specific way of kicking. consult
your hypervisor manual and cpuid bits for further details. should you
not be satisfied with this method, port io is still available.
Avi Kivity wrote:
Unfortunately, we have to care for platform differences, subarch
differences (vmx/svm), hypervisor differences (with virtio), and guest
differences (Linux/Windows/pvLinux, 32/64). Much care is needed when
designing the ABI here.
Yea, I agree.
[actually thinking a bit, this
Avi Kivity wrote:
We intend to bind our virtio devices to PCI too, so that they look the
same in Linux userland across architectures.
Ouch.
That was my initial opinion too, but HPA has come up with a lean and
clean PCI binding for lguest. I think we should seriously consider
using that over
Avi Kivity wrote:
I pulled yesterday so it should be all right (and you don't need me for
that; you can pull from Linus on top of kvm.git).
The machine runs kvm.git for a while now, seems to work ok.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Avi Kivity wrote:
I pulled yesterday so it should be all right (and you don't need me for
that; you can pull from Linus on top of kvm.git).
Thanks :-).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Avi Kivity wrote:
kvm.git is actually 2.6.24-rc, pulled from -linus at a random point in
time, so it's not at all surprising if something is broken.
Right. We have a backup now, so next time we'll be ok ;-). Would you
please pull from Linus again to get the fix into kvm.git so that we
can use
Avi Kivity wrote:
kvm.git is actually 2.6.24-rc, pulled from -linus at a random point in
time, so it's not at all surprising if something is broken.
Right. We have a backup now, so next time we'll be ok ;-). Would you
please pull from Linus again to get the fix into kvm.git so that we
can use
Avi Kivity wrote:
I pulled yesterday so it should be all right (and you don't need me for
that; you can pull from Linus on top of kvm.git).
Thanks :-).
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Avi Kivity wrote:
I pulled yesterday so it should be all right (and you don't need me for
that; you can pull from Linus on top of kvm.git).
The machine runs kvm.git for a while now, seems to work ok.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Carsten Otte wrote:
First thing we do, is figure whether or not 2.6.23.1 as released breaks
our system too. This way, we can either focus on differences between
Linus and Avi, or turn on the big red warning sign saying "regression".
Looks like 2.6.23.1 works fine on that box. W
Mike Lampard wrote:
There was a commit ab9c232286c2b77be78441c2d8396500b045777e regarding libata
on linus's master tree that happened on Friday, that was pulled into kvm git
over the weekend.. I dont know if that may be affecting you.. there is/was
also chatter on LKML regarding some problems
Carsten Otte wrote:
2.6.23 is broken, 2.6.23-rc8 works for us.
Actually, the working version was 2.6.23-rc6, git-head of kvm.git as
of October 11.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
Laurent Vivier wrote:
How do you know the problem has been introduced by kvm ?
I don't. In fact I think it has not been introduced by kvm. All I
stated, is that we experienced the problem when running the kvm.git
kernel after the 2.6.23 update that has not been present in the
kvm.git -rc8 as
Aurelien Jarno wrote:
Could you please precise what is corrupted? The guest disk image?
As stated, we actually did not run any guests and did not load the kvm
kernel modules.
The host root file system gets corrupted to an extend not correctable
by the file system checker (we gave it 24h to
Hi list,
we've experienced a severe bug in current kvm.git, that may have been
introduced to the git tree quite recently around last weekend. 2.6.23
is broken, 2.6.23-rc8 works for us. The symptom is, that our operon
kvm test machine shredders its hard disk content to a state that is
not
Mike Lampard wrote:
There was a commit ab9c232286c2b77be78441c2d8396500b045777e regarding libata
on linus's master tree that happened on Friday, that was pulled into kvm git
over the weekend.. I dont know if that may be affecting you.. there is/was
also chatter on LKML regarding some problems
Carsten Otte wrote:
2.6.23 is broken, 2.6.23-rc8 works for us.
Actually, the working version was 2.6.23-rc6, git-head of kvm.git as
of October 11.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
Aurelien Jarno wrote:
Could you please precise what is corrupted? The guest disk image?
As stated, we actually did not run any guests and did not load the kvm
kernel modules.
The host root file system gets corrupted to an extend not correctable
by the file system checker (we gave it 24h to
Hi list,
we've experienced a severe bug in current kvm.git, that may have been
introduced to the git tree quite recently around last weekend. 2.6.23
is broken, 2.6.23-rc8 works for us. The symptom is, that our operon
kvm test machine shredders its hard disk content to a state that is
not
Carsten Otte wrote:
First thing we do, is figure whether or not 2.6.23.1 as released breaks
our system too. This way, we can either focus on differences between
Linus and Avi, or turn on the big red warning sign saying regression.
Looks like 2.6.23.1 works fine on that box. We'll leave
Laurent Vivier wrote:
How do you know the problem has been introduced by kvm ?
I don't. In fact I think it has not been introduced by kvm. All I
stated, is that we experienced the problem when running the kvm.git
kernel after the 2.6.23 update that has not been present in the
kvm.git -rc8 as
Jeff Dike wrote:
I want it to be identity-mapped, which a single address space would
guarantee. For things which change mappings, like vmalloc, I need to
be in the same address space as the guest.
That'll also be mandatory required by hw when porting this to s390.
-
To unsubscribe from this
Jeff Dike wrote:
I want it to be identity-mapped, which a single address space would
guarantee. For things which change mappings, like vmalloc, I need to
be in the same address space as the guest.
That'll also be mandatory required by hw when porting this to s390.
-
To unsubscribe from this
this patch to -mm.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
Index: linux-2.6.22-rc4-mm/fs/ext2/super.c
===
--- linux-2.6.22-rc4-mm.orig/fs/ext2/super.c
+++ linux-2.6.22-rc4-mm/fs/ext2/super.c
@@ -1071,6 +1071,14 @@ stat
Yan Zheng wrote:
I mount an ext2 fs , then remount it with xip option set.
I get message below when do write operation in the fs.
Ouch. Like on mount, we should refuse -o xip on remount. The patch
below fixes this issue.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
Index: linux-
Yan Zheng wrote:
I mount an ext2 fs , then remount it with xip option set.
I get message below when do write operation in the fs.
Ouch. Like on mount, we should refuse -o xip on remount. The patch
below fixes this issue.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
Index: linux-2.6.22
this patch to -mm.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
Index: linux-2.6.22-rc4-mm/fs/ext2/super.c
===
--- linux-2.6.22-rc4-mm.orig/fs/ext2/super.c
+++ linux-2.6.22-rc4-mm/fs/ext2/super.c
@@ -1071,6 +1071,14 @@ static int
Jared Hulbert wrote:
We would still need to add the kernel mapping though.
But that's handled by ioremap()ing it right?
That's right. Ioremap will give you a permanent kernel space mapping
until you do iounmap() again.
-
To unsubscribe from this list: send the line "unsubscribe
Jared Hulbert wrote:
We would still need to add the kernel mapping though.
But that's handled by ioremap()ing it right?
That's right. Ioremap will give you a permanent kernel space mapping
until you do iounmap() again.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Nick Piggin wrote:
Carsten Otte wrote:
The current xip stack relies on having struct page behind the memory
segment. This causes few impact on memory management, but occupies
some more memory. The cramfs patch chose to modify copy on write in
order to deal with vmas that don't have struct
Jared Hulbert wrote:
An alternative approach, which does not need to have struct page at
hand, would be to use the nopfn vm operations struct. That one would
have to rely on get_xip_pfn.
Of course! Okay now I'm begining to understand.
Sorry, but I think I was educated yesterday that ->fault()
Jared Hulbert wrote:
An alternative approach, which does not need to have struct page at
hand, would be to use the nopfn vm operations struct. That one would
have to rely on get_xip_pfn.
Of course! Okay now I'm begining to understand.
Sorry, but I think I was educated yesterday that -fault()
Nick Piggin wrote:
Carsten Otte wrote:
The current xip stack relies on having struct page behind the memory
segment. This causes few impact on memory management, but occupies
some more memory. The cramfs patch chose to modify copy on write in
order to deal with vmas that don't have struct
struct page behind the xip memory
segment. We'd like to get rid of that in favor of supporting flash based
embedded platforms (Monta Vista work) soon.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
Index: linux-2.6.21/fs/ext2/
Jared Hulbert wrote:
Nick Piggin wrote:
> The question is, why is that not enough (I haven't looked at these
> patches enough to work out if there is anything more they provide).
I think, it just takes trying things out. From reading the code, I
think this should work well for the filemap_xip
Jared Hulbert wrote:
Nick Piggin wrote:
The question is, why is that not enough (I haven't looked at these
patches enough to work out if there is anything more they provide).
I think, it just takes trying things out. From reading the code, I
think this should work well for the filemap_xip code
struct page behind the xip memory
segment. We'd like to get rid of that in favor of supporting flash based
embedded platforms (Monta Vista work) soon.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
Index: linux-2.6.21/fs/ext2/file.c
Justin Treon wrote:
--- Carsten Otte <[EMAIL PROTECTED]> wrote:
The nice thing about this approach is: we use page->count and rmap,
both already exist and are perfectly suited for our purpose.
The downside: We need mem_map[] struct page entries behind all memory
segments. Nowerda
Jörn Engel wrote:
Whenever writes/erases to the device happen, the device driver would
need to call a function like
/**
* unmap_page_range - remove all mapping to the given range of an address space
* @mapping - the address space in question
* @start_index - index of the first page in the
Jörn Engel wrote:
Whenever writes/erases to the device happen, the device driver would
need to call a function like
/**
* unmap_page_range - remove all mapping to the given range of an address space
* @mapping - the address space in question
* @start_index - index of the first page in the
Justin Treon wrote:
--- Carsten Otte [EMAIL PROTECTED] wrote:
The nice thing about this approach is: we use page-count and rmap,
both already exist and are perfectly suited for our purpose.
The downside: We need mem_map[] struct page entries behind all memory
segments. Nowerdays we can easily
Carsten Otte wrote:
- temporary references (for read/write syscalls and friends) get
retrieved via get_xip_page and returned again via to-be-invented
put_page/page_cache_release
Doh! Meant to state: returned again via stock
put_page/page_cache_release rather then inventing something new
Jörn Engel wrote:
Nitbit: Sooner or later the point/unpoint should get replaced by
something with page granularity. Something also needs to keep lists of
mapped pages and invalidate them whenever the device is written to.
That could be done in the filesystem or device driver. I believe the
Christoph Hellwig wrote:
Jared's patch currently does ioremap on mount (and no iounmap at all).
That mapping needs to move from the filesystem to the device driver.
The device driver needs to do ioremap on open(), and iounmap() on
release. That's effectively what our block driver does.
-
To
Christoph Hellwig wrote:
We can have a simpler variant as a start if we really want. But we
need to pass it through the mtd layer. There is a reason we have this
thing called devices drivers, and we don't want to add knowledge of
ioremap to the filesystems and have users find out physical
Christoph Hellwig wrote:
And for thus just wanting to take a quick glance, this is the
diff vs an out of tree cramfs where uncompress.c and cramfs_fs_sb.h
are merged into inode.c:
Mkay, I am convinced. Either cramfs should be based on a block device
that does have direct_access() for xip, or
Christoph Hellwig wrote:
On Thu, Jun 07, 2007 at 07:07:54PM +0200, Carsten Otte wrote:
I've had a few beer long discussion with Joern Engel and David
Woodhouse on this one. To cut a long discussion short: the current XIP
infrastructure is not sufficient to be used on top of mtd. We'd need
Christoph Hellwig wrote:
On Thu, Jun 07, 2007 at 07:07:54PM +0200, Carsten Otte wrote:
I've had a few beer long discussion with Joern Engel and David
Woodhouse on this one. To cut a long discussion short: the current XIP
infrastructure is not sufficient to be used on top of mtd. We'd need
Christoph Hellwig wrote:
We can have a simpler variant as a start if we really want. But we
need to pass it through the mtd layer. There is a reason we have this
thing called devices drivers, and we don't want to add knowledge of
ioremap to the filesystems and have users find out physical
Christoph Hellwig wrote:
And for thus just wanting to take a quick glance, this is the
diff vs an out of tree cramfs where uncompress.c and cramfs_fs_sb.h
are merged into inode.c:
Mkay, I am convinced. Either cramfs should be based on a block device
that does have direct_access() for xip, or
Christoph Hellwig wrote:
Jared's patch currently does ioremap on mount (and no iounmap at all).
That mapping needs to move from the filesystem to the device driver.
The device driver needs to do ioremap on open(), and iounmap() on
release. That's effectively what our block driver does.
-
To
Jörn Engel wrote:
Nitbit: Sooner or later the point/unpoint should get replaced by
something with page granularity. Something also needs to keep lists of
mapped pages and invalidate them whenever the device is written to.
That could be done in the filesystem or device driver. I believe the
Carsten Otte wrote:
- temporary references (for read/write syscalls and friends) get
retrieved via get_xip_page and returned again via to-be-invented
put_page/page_cache_release
Doh! Meant to state: returned again via stock
put_page/page_cache_release rather then inventing something new
Christoph Hellwig wrote:
The right way to architect xip for flash-based devices is to implement
a generic get_xip_page for mtd-based devices and integrate that into
an existing flash filesystem or write a simple new flash filesystem
tailored to that use case.
I've had a few beer long discussion
Christoph Hellwig wrote:
The right way to architect xip for flash-based devices is to implement
a generic get_xip_page for mtd-based devices and integrate that into
an existing flash filesystem or write a simple new flash filesystem
tailored to that use case.
I've had a few beer long discussion
Christoph Hellwig wrote:
I might be a little late in the discussion, but I somehow missed this
before. Please don't add this xip support to cramfs, because the
whole point of cramfs is to be a simple _compressed_ filesystem,
and we really don't want to add more complexity to it. Please
use
Jared Hulbert wrote:
(2) failed with the following messages. (This wasn't really busybox.
It was xxd, not statically link, hence the issue with ld.so)
Could you try to figure what happend to subject page before? Was it
subject to copy on write? With what flags has this vma been mmaped?
Jared Hulbert wrote:
(2) failed with the following messages. (This wasn't really busybox.
It was xxd, not statically link, hence the issue with ld.so)
Could you try to figure what happend to subject page before? Was it
subject to copy on write? With what flags has this vma been mmaped?
Christoph Hellwig wrote:
I might be a little late in the discussion, but I somehow missed this
before. Please don't add this xip support to cramfs, because the
whole point of cramfs is to be a simple _compressed_ filesystem,
and we really don't want to add more complexity to it. Please
use
Vasily Averin wrote:
Customers claims to ext3-related errors, investigation showed that ext3 orphan
list has been corrupted and have the reference to non-ext3 inode. The following
debug helps to understand the reasons of this issue.
This looks like it might be related to the -as far as I recall-
Vasily Averin wrote:
Customers claims to ext3-related errors, investigation showed that ext3 orphan
list has been corrupted and have the reference to non-ext3 inode. The following
debug helps to understand the reasons of this issue.
This looks like it might be related to the -as far as I recall-
Nick Piggin wrote:
The question is, why is that not enough (I haven't looked at these
patches enough to work out if there is anything more they provide).
I think, it just takes trying things out. From reading the code, I
think this should work well for the filemap_xip code with no struct page.
Nick Piggin wrote:
The question is, why is that not enough (I haven't looked at these
patches enough to work out if there is anything more they provide).
I think, it just takes trying things out. From reading the code, I
think this should work well for the filemap_xip code with no struct page.
it in splice.c or should it go to filemap_xip?
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
it in splice.c or should it go to filemap_xip?
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
Jared Hulbert wrote:
To me, it looks like this
work can be modified to use filemap_xip.
How?
First, get a struct page behind the subject file system image. A good
idea to get there is to use vmem_map, which allows have a
discontiguous mem_map array in virtual storage. Then add the memory
Richard Griffiths (wrs) wrote:
One question I have is the difference in the two models. If I understand
correctly the filemap_xip expects the ext2 to mount as XIP while the
Linear Cramfs only enables XIP for apps that have the sticky bit set.
Hence the Application XIP moniker.
Does the
Richard Griffiths (wrs) wrote:
One question I have is the difference in the two models. If I understand
correctly the filemap_xip expects the ext2 to mount as XIP while the
Linear Cramfs only enables XIP for apps that have the sticky bit set.
Hence the Application XIP moniker.
Does the
Jared Hulbert wrote:
To me, it looks like this
work can be modified to use filemap_xip.
How?
First, get a struct page behind the subject file system image. A good
idea to get there is to use vmem_map, which allows have a
discontiguous mem_map array in virtual storage. Then add the memory
Andrew Morton wrote:
But we'd expected and hoped that flash-based XIP would be able to use
the existing xip infrastructure, in mm/filemap_xip.c. Not possible?
Thanks for the heads up Andrew. Reading the cramfs patch, I've found a
lot of similarities between the current mainline xip stack and
Andrew Morton wrote:
But we'd expected and hoped that flash-based XIP would be able to use
the existing xip infrastructure, in mm/filemap_xip.c. Not possible?
Thanks for the heads up Andrew. Reading the cramfs patch, I've found a
lot of similarities between the current mainline xip stack and
On 5/14/07, Bharata B Rao <[EMAIL PROTECTED]> wrote:
+/* This is a copy from fs/readdir.c */
+struct getdents_callback {
+ struct linux_dirent __user *current_dir;
+ struct linux_dirent __user *previous;
+ int count;
+ int error;
+};
This should go into a header file.
On 5/14/07, Bharata B Rao [EMAIL PROTECTED] wrote:
+/* This is a copy from fs/readdir.c */
+struct getdents_callback {
+ struct linux_dirent __user *current_dir;
+ struct linux_dirent __user *previous;
+ int count;
+ int error;
+};
This should go into a header file.
On 3/8/07, Martin Drab <[EMAIL PROTECTED]> wrote:
The thing is that I'd like to prevent kernel to swap these pages out,
because then I may loose some data when they are not available in time
for the next round.
One think you could do is grab a reference to the pages upfront. When
you stop
On 3/8/07, Martin Drab [EMAIL PROTECTED] wrote:
The thing is that I'd like to prevent kernel to swap these pages out,
because then I may loose some data when they are not available in time
for the next round.
One think you could do is grab a reference to the pages upfront. When
you stop
On 8/21/05, Pekka Enberg <[EMAIL PROTECTED]> wrote:
> This patch updates the out-of-date Documentation/filesystems/vfs.txt.
> As I am a novice on the VFS, I would much appreciate any comments and
> help on this.
Cool, thanks for updating it :)
> + get_xip_page: called by the VM to translate a
On 8/21/05, Pekka Enberg [EMAIL PROTECTED] wrote:
This patch updates the out-of-date Documentation/filesystems/vfs.txt.
As I am a novice on the VFS, I would much appreciate any comments and
help on this.
Cool, thanks for updating it :)
+ get_xip_page: called by the VM to translate a block
triggers where it should not. The problem
was introduced by a cleanup in my previous patch, this patch fixes it.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
diff -ruwN linux-git/fs/ext2/xip.c linux-git-xip-fixup/fs/ext2/xip.c
--- linux-git/fs/ext2/xip.c 2005-07-25 17:18:38.000
triggers where it should not. The problem
was introduced by a cleanup in my previous patch, this patch fixes it.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
diff -ruwN linux-git/fs/ext2/xip.c linux-git-xip-fixup/fs/ext2/xip.c
--- linux-git/fs/ext2/xip.c 2005-07-25 17:18:38.0 +0200
98 matches
Mail list logo
