Re: Resend inlined text: [PATCH] Minor cleanup and export three functions
At 03:58 20/07/2001, Anton Altaparmakov wrote: >This is clearly not my day for sending emails... > >Sorry. The attachment was fine on last email but a little misunderstanding >between elm and myself resulted in the invention of two non-existent email >addresses and put them in the To: field. )-: Just remove them before >replying... They are quite obvious: [EMAIL PROTECTED], [EMAIL PROTECTED] > >Just trying to preempt the flames I am bound to get for that mess up... At >least I know how to do it properly next time. (-: And I just realized I can't spell Torvalds properly either. Linus, sincerely I apologize. I am going away to hide my head in the sand now... /-: Best regards, Anton -- "Nothing succeeds like success." - Alexandre Dumas -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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://www.tux.org/lkml/
Re: Resend inlined text: [PATCH] Minor cleanup and export three functions
This is clearly not my day for sending emails... Sorry. The attachment was fine on last email but a little misunderstanding between elm and myself resulted in the invention of two non-existent email addresses and put them in the To: field. )-: Just remove them before replying... They are quite obvious: [EMAIL PROTECTED], [EMAIL PROTECTED] Just trying to preempt the flames I am bound to get for that mess up... At least I know how to do it properly next time. (-: Anton -- "Nothing succeeds like success." - Alexandre Dumas -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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://www.tux.org/lkml/
Resend inlined text: [PATCH] Minor cleanup and export three functions
Sorry for confusion. Here goes again, sent with elm, and tested for being
clear text inline and that white space is not mangled.
-
Linus,
Please consider attached patch. It does three things:
- Adds docbook style comments to a very few functions relating to the page
cache (mm/filemap.c) and does very minor clean up on those to keep within
80 character wide lines (only look affected).
- Minor cleanup making the offset/index parameter "const" in those
functions.
- More importantly, the patch exports the following three functions:
from mm/filemap.c (adding to include/linux/pagemap.h):
__find_page_nolock()
__add_to_page_cache()
from fs/buffer.c (adding to include/linux/fs.h):
create_empty_buffers()
The static keyword is removed, they are added to the indicated header
files as extern or extern inline as appropriate, and they are also added
to kernel/ksyms.c.
These three functions are used by the new NTFS driver which is under
development and in specific in the inode metadata in page cache part. I
have looked at alternatives but they lead to much nastier complications
within the ntfs code. (E.g. due to forcing me to drop the pagecache_lock
if I were to use add_to_page_cache() function instead of
__add_to_page_cache() which would in turn lead to potential race
condition, and anyway dropping the lock to only reacquire it straight
after returning after the function seems very inefficient.)
Any objections to the patch? If not, please apply. Thanks!
Best regards,
Anton
--
Anton Altaparmakov (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
--- Patch follows this line ---
diff -urN linux-2.4.7-pre8-vanilla/fs/buffer.c
linux-2.4.7-pre8-tng-mrproper/fs/buffer.c
--- linux-2.4.7-pre8-vanilla/fs/buffer.cThu Jul 19 18:53:17 2001
+++ linux-2.4.7-pre8-tng-mrproper/fs/buffer.c Thu Jul 19 20:45:00 2001
@@ -1434,7 +1434,8 @@
return 1;
}
-static void create_empty_buffers(struct page *page, kdev_t dev, unsigned long
blocksize)
+void create_empty_buffers(struct page *page, kdev_t dev,
+ unsigned long blocksize)
{
struct buffer_head *bh, *head, *tail;
diff -urN linux-2.4.7-pre8-vanilla/include/linux/fs.h
linux-2.4.7-pre8-tng-mrproper/include/linux/fs.h
--- linux-2.4.7-pre8-vanilla/include/linux/fs.h Thu Jul 19 18:53:19 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/fs.hThu Jul 19 23:02:10 2001
@@ -1320,6 +1320,8 @@
typedef int (get_block_t)(struct inode*,long,struct buffer_head*,int);
+extern void create_empty_buffers(struct page *, kdev_t, unsigned long);
+
/* Generic buffer handling for block filesystems.. */
extern int block_flushpage(struct page *, unsigned long);
extern int block_symlink(struct inode *, const char *, int);
diff -urN linux-2.4.7-pre8-vanilla/include/linux/pagemap.h
linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h
--- linux-2.4.7-pre8-vanilla/include/linux/pagemap.hTue Jul 3 23:42:57 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h Thu Jul 19 21:08:33
+2001
@@ -60,7 +60,8 @@
* For the time being it will work for struct address_space too (most of
* them sitting inside the inodes). We might want to change it later.
*/
-extern inline unsigned long _page_hashfn(struct address_space * mapping, unsigned
long index)
+extern inline unsigned long _page_hashfn(struct address_space *mapping,
+ const unsigned long index)
{
#define i (((unsigned long) mapping)/(sizeof(struct inode) & ~ (sizeof(struct inode)
- 1)))
#define s(x) ((x)+((x)>>PAGE_HASH_BITS))
@@ -75,6 +76,8 @@
unsigned long offset, struct page **hash);
extern struct page * __find_lock_page (struct address_space * mapping,
unsigned long index, struct page **hash);
+extern inline struct page *__find_page_nolock(struct address_space *mapping,
+ const unsigned long offset, struct page *page);
extern void lock_page(struct page *page);
#define find_lock_page(mapping, index) \
__find_lock_page(mapping, index, page_hash(mapping, index))
@@ -86,8 +89,13 @@
extern void __add_page_to_hash_queue(struct page * page, struct page **p);
-extern void add_to_page_cache(struct page * page, struct address_space *mapping,
unsigned long index);
-extern void add_to_page_cache_locked(struct page * page, struct address_space
*mapping, unsigned long index);
+extern inline void __add_to_page_cache(struct page *page,
+ struct address_space *mapping, const unsigned long offset,
+ struct page **hash);
+extern void add_to_page_cache(struct page *page, struct address_space *mapping,
+ const unsigned long index);
+extern void add_to_page_cache_locked(struct page *page,
+ struct address_space *mapping, const unsigned long index);
extern void ___wait_on_page(struct page *);
Re: [PATCH] Minor cleanup and export three functions
At 3:03 AM +0100 2001-07-20, Anton Altaparmakov wrote: >I do appologize. I didn't realize pine would do this. In pine I can just >read the attachment as text and in Eudora it just appears as inlined >text without any indication of it being a separate attachment, so I just >assumed that it was sent clear text. Obviously not. Eudora does leave you one little clue: At 2:19 AM +0100 2001-07-20, Anton Altaparmakov wrote: >MIME-Version: 1.0 >Content-Type: MULTIPART/MIXED; >BOUNDARY="-559023410-1804928587-995591940=:20239" -- /Jonathan Lundell. - 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://www.tux.org/lkml/
Re: [PATCH] Minor cleanup and export three functions
On Fri, 20 Jul 2001 03:03:58 +0100 (BST), Anton Altaparmakov <[EMAIL PROTECTED]> wrote: > I will repost as soon as I manage to convince pine of it's wrong ways... You can't, so don't bother. Just inline it, ctrl-r should do the trick. However be careful, newer pine's like to strip trailing spaces even from inlined files -- I've fixed mine but most distributions have the broken one. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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://www.tux.org/lkml/
Re: [PATCH] Minor cleanup and export three functions
On Thu, 19 Jul 2001, Pete Zaitcev wrote: > > This message is in MIME format. The first part should be readable text, > > while the remaining parts are likely unreadable without MIME-aware tools. > > Quite so. Linus told you many times not to send patches > in MIME and I happen to agree. > > > Content-Type: TEXT/PLAIN; charset=US-ASCII; name="patch-2.4.7-pre8-aia1" > > Content-Transfer-Encoding: BASE64 > > Content-ID: <[EMAIL PROTECTED]> > > Content-Description: > > > > ZGlmZiAtdXJOIGxpbnV4LTIuNC43LXByZTgtdmFuaWxsYS9mcy9idWZmZXIu > > YyBsaW51eC0yLjQuNy1wcmU4LXRuZy1tcnByb3Blci9mcy9idWZmZXIuYw0K > >[ lots of crap skipped ] > I do appologize. I didn't realize pine would do this. In pine I can just read the attachment as text and in Eudora it just appears as inlined text without any indication of it being a separate attachment, so I just assumed that it was sent clear text. Obviously not. I will repost as soon as I manage to convince pine of it's wrong ways... Best regards, Anton -- Anton Altaparmakov (replace at with @) Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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://www.tux.org/lkml/
Re: [PATCH] Minor cleanup and export three functions
> This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. Quite so. Linus told you many times not to send patches in MIME and I happen to agree. > Content-Type: TEXT/PLAIN; charset=US-ASCII; name="patch-2.4.7-pre8-aia1" > Content-Transfer-Encoding: BASE64 > Content-ID: <[EMAIL PROTECTED]> > Content-Description: > > ZGlmZiAtdXJOIGxpbnV4LTIuNC43LXByZTgtdmFuaWxsYS9mcy9idWZmZXIu > YyBsaW51eC0yLjQuNy1wcmU4LXRuZy1tcnByb3Blci9mcy9idWZmZXIuYw0K >[ lots of crap skipped ] - 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://www.tux.org/lkml/
[PATCH] Minor cleanup and export three functions
Linus,
Please consider attached patch. It does three things:
- Adds docbook style comments to a very few functions relating to the page
cache (mm/filemap.c) and does very minor clean up on those to keep within
80 character wide lines (only look affected).
- Minor cleanup making the offset/index parameter "const" in those
functions.
- More importantly, the patch exports the following three functions:
from mm/filemap.c (adding to include/linux/pagemap.h):
__find_page_nolock()
__add_to_page_cache()
from fs/buffer.c (adding to include/linux/fs.h):
create_empty_buffers()
The static keyword is removed, they are added to the indicated header
files as extern or extern inline as appropriate, and they are also added
to kernel/ksyms.c.
These three functions are used by the new NTFS driver which is under
development and in specific in the inode metadata in page cache part. I
have looked at alternatives but they lead to much nastier complications
within the ntfs code. (E.g. due to forcing me to drop the pagecache_lock
if I were to use add_to_page_cache() function instead of
__add_to_page_cache() which would in turn lead to potential race
condition, and anyway dropping the lock to only reacquire it straight
after returning after the function seems very inefficient.)
Any objections to the patch? If not, please apply. Thanks!
Best regards,
Anton
--
Anton Altaparmakov (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
diff -urN linux-2.4.7-pre8-vanilla/fs/buffer.c
linux-2.4.7-pre8-tng-mrproper/fs/buffer.c
--- linux-2.4.7-pre8-vanilla/fs/buffer.cThu Jul 19 18:53:17 2001
+++ linux-2.4.7-pre8-tng-mrproper/fs/buffer.c Thu Jul 19 20:45:00 2001
@@ -1434,7 +1434,8 @@
return 1;
}
-static void create_empty_buffers(struct page *page, kdev_t dev, unsigned long
blocksize)
+void create_empty_buffers(struct page *page, kdev_t dev,
+ unsigned long blocksize)
{
struct buffer_head *bh, *head, *tail;
diff -urN linux-2.4.7-pre8-vanilla/include/linux/fs.h
linux-2.4.7-pre8-tng-mrproper/include/linux/fs.h
--- linux-2.4.7-pre8-vanilla/include/linux/fs.h Thu Jul 19 18:53:19 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/fs.hThu Jul 19 23:02:10 2001
@@ -1320,6 +1320,8 @@
typedef int (get_block_t)(struct inode*,long,struct buffer_head*,int);
+extern void create_empty_buffers(struct page *, kdev_t, unsigned long);
+
/* Generic buffer handling for block filesystems.. */
extern int block_flushpage(struct page *, unsigned long);
extern int block_symlink(struct inode *, const char *, int);
diff -urN linux-2.4.7-pre8-vanilla/include/linux/pagemap.h
linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h
--- linux-2.4.7-pre8-vanilla/include/linux/pagemap.hTue Jul 3 23:42:57 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h Thu Jul 19 21:08:33
+2001
@@ -60,7 +60,8 @@
* For the time being it will work for struct address_space too (most of
* them sitting inside the inodes). We might want to change it later.
*/
-extern inline unsigned long _page_hashfn(struct address_space * mapping, unsigned
long index)
+extern inline unsigned long _page_hashfn(struct address_space *mapping,
+ const unsigned long index)
{
#define i (((unsigned long) mapping)/(sizeof(struct inode) & ~ (sizeof(struct inode)
- 1)))
#define s(x) ((x)+((x)>>PAGE_HASH_BITS))
@@ -75,6 +76,8 @@
unsigned long offset, struct page **hash);
extern struct page * __find_lock_page (struct address_space * mapping,
unsigned long index, struct page **hash);
+extern inline struct page *__find_page_nolock(struct address_space *mapping,
+ const unsigned long offset, struct page *page);
extern void lock_page(struct page *page);
#define find_lock_page(mapping, index) \
__find_lock_page(mapping, index, page_hash(mapping, index))
@@ -86,8 +89,13 @@
extern void __add_page_to_hash_queue(struct page * page, struct page **p);
-extern void add_to_page_cache(struct page * page, struct address_space *mapping,
unsigned long index);
-extern void add_to_page_cache_locked(struct page * page, struct address_space
*mapping, unsigned long index);
+extern inline void __add_to_page_cache(struct page *page,
+ struct address_space *mapping, const unsigned long offset,
+ struct page **hash);
+extern void add_to_page_cache(struct page *page, struct address_space *mapping,
+ const unsigned long index);
+extern void add_to_page_cache_locked(struct page *page,
+ struct address_space *mapping, const unsigned long index);
extern void ___wait_on_page(struct page *);
diff -urN linux-2.4.7-pre8-vanilla/kernel/ksyms.c
linux-2.4.7-pre8-tng-mrproper/kernel/ksyms.c
---
[PATCH] Minor cleanup and export three functions
Linus,
Please consider attached patch. It does three things:
- Adds docbook style comments to a very few functions relating to the page
cache (mm/filemap.c) and does very minor clean up on those to keep within
80 character wide lines (only look affected).
- Minor cleanup making the offset/index parameter const in those
functions.
- More importantly, the patch exports the following three functions:
from mm/filemap.c (adding to include/linux/pagemap.h):
__find_page_nolock()
__add_to_page_cache()
from fs/buffer.c (adding to include/linux/fs.h):
create_empty_buffers()
The static keyword is removed, they are added to the indicated header
files as extern or extern inline as appropriate, and they are also added
to kernel/ksyms.c.
These three functions are used by the new NTFS driver which is under
development and in specific in the inode metadata in page cache part. I
have looked at alternatives but they lead to much nastier complications
within the ntfs code. (E.g. due to forcing me to drop the pagecache_lock
if I were to use add_to_page_cache() function instead of
__add_to_page_cache() which would in turn lead to potential race
condition, and anyway dropping the lock to only reacquire it straight
after returning after the function seems very inefficient.)
Any objections to the patch? If not, please apply. Thanks!
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
diff -urN linux-2.4.7-pre8-vanilla/fs/buffer.c
linux-2.4.7-pre8-tng-mrproper/fs/buffer.c
--- linux-2.4.7-pre8-vanilla/fs/buffer.cThu Jul 19 18:53:17 2001
+++ linux-2.4.7-pre8-tng-mrproper/fs/buffer.c Thu Jul 19 20:45:00 2001
@@ -1434,7 +1434,8 @@
return 1;
}
-static void create_empty_buffers(struct page *page, kdev_t dev, unsigned long
blocksize)
+void create_empty_buffers(struct page *page, kdev_t dev,
+ unsigned long blocksize)
{
struct buffer_head *bh, *head, *tail;
diff -urN linux-2.4.7-pre8-vanilla/include/linux/fs.h
linux-2.4.7-pre8-tng-mrproper/include/linux/fs.h
--- linux-2.4.7-pre8-vanilla/include/linux/fs.h Thu Jul 19 18:53:19 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/fs.hThu Jul 19 23:02:10 2001
@@ -1320,6 +1320,8 @@
typedef int (get_block_t)(struct inode*,long,struct buffer_head*,int);
+extern void create_empty_buffers(struct page *, kdev_t, unsigned long);
+
/* Generic buffer handling for block filesystems.. */
extern int block_flushpage(struct page *, unsigned long);
extern int block_symlink(struct inode *, const char *, int);
diff -urN linux-2.4.7-pre8-vanilla/include/linux/pagemap.h
linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h
--- linux-2.4.7-pre8-vanilla/include/linux/pagemap.hTue Jul 3 23:42:57 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h Thu Jul 19 21:08:33
+2001
@@ -60,7 +60,8 @@
* For the time being it will work for struct address_space too (most of
* them sitting inside the inodes). We might want to change it later.
*/
-extern inline unsigned long _page_hashfn(struct address_space * mapping, unsigned
long index)
+extern inline unsigned long _page_hashfn(struct address_space *mapping,
+ const unsigned long index)
{
#define i (((unsigned long) mapping)/(sizeof(struct inode) ~ (sizeof(struct inode)
- 1)))
#define s(x) ((x)+((x)PAGE_HASH_BITS))
@@ -75,6 +76,8 @@
unsigned long offset, struct page **hash);
extern struct page * __find_lock_page (struct address_space * mapping,
unsigned long index, struct page **hash);
+extern inline struct page *__find_page_nolock(struct address_space *mapping,
+ const unsigned long offset, struct page *page);
extern void lock_page(struct page *page);
#define find_lock_page(mapping, index) \
__find_lock_page(mapping, index, page_hash(mapping, index))
@@ -86,8 +89,13 @@
extern void __add_page_to_hash_queue(struct page * page, struct page **p);
-extern void add_to_page_cache(struct page * page, struct address_space *mapping,
unsigned long index);
-extern void add_to_page_cache_locked(struct page * page, struct address_space
*mapping, unsigned long index);
+extern inline void __add_to_page_cache(struct page *page,
+ struct address_space *mapping, const unsigned long offset,
+ struct page **hash);
+extern void add_to_page_cache(struct page *page, struct address_space *mapping,
+ const unsigned long index);
+extern void add_to_page_cache_locked(struct page *page,
+ struct address_space *mapping, const unsigned long index);
extern void ___wait_on_page(struct page *);
diff -urN linux-2.4.7-pre8-vanilla/kernel/ksyms.c
linux-2.4.7-pre8-tng-mrproper/kernel/ksyms.c
Re: [PATCH] Minor cleanup and export three functions
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Quite so. Linus told you many times not to send patches in MIME and I happen to agree. Content-Type: TEXT/PLAIN; charset=US-ASCII; name=patch-2.4.7-pre8-aia1 Content-Transfer-Encoding: BASE64 Content-ID: [EMAIL PROTECTED] Content-Description: ZGlmZiAtdXJOIGxpbnV4LTIuNC43LXByZTgtdmFuaWxsYS9mcy9idWZmZXIu YyBsaW51eC0yLjQuNy1wcmU4LXRuZy1tcnByb3Blci9mcy9idWZmZXIuYw0K [ lots of crap skipped ] - 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://www.tux.org/lkml/
Re: [PATCH] Minor cleanup and export three functions
On Thu, 19 Jul 2001, Pete Zaitcev wrote: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Quite so. Linus told you many times not to send patches in MIME and I happen to agree. Content-Type: TEXT/PLAIN; charset=US-ASCII; name=patch-2.4.7-pre8-aia1 Content-Transfer-Encoding: BASE64 Content-ID: [EMAIL PROTECTED] Content-Description: ZGlmZiAtdXJOIGxpbnV4LTIuNC43LXByZTgtdmFuaWxsYS9mcy9idWZmZXIu YyBsaW51eC0yLjQuNy1wcmU4LXRuZy1tcnByb3Blci9mcy9idWZmZXIuYw0K [ lots of crap skipped ] I do appologize. I didn't realize pine would do this. In pine I can just read the attachment as text and in Eudora it just appears as inlined text without any indication of it being a separate attachment, so I just assumed that it was sent clear text. Obviously not. Stupid mailers. Grr. I will repost as soon as I manage to convince pine of it's wrong ways... Best regards, Anton -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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://www.tux.org/lkml/
Re: [PATCH] Minor cleanup and export three functions
On Fri, 20 Jul 2001 03:03:58 +0100 (BST), Anton Altaparmakov [EMAIL PROTECTED] wrote: I will repost as soon as I manage to convince pine of it's wrong ways... You can't, so don't bother. Just inline it, ctrl-r should do the trick. However be careful, newer pine's like to strip trailing spaces even from inlined files -- I've fixed mine but most distributions have the broken one. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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://www.tux.org/lkml/
Re: [PATCH] Minor cleanup and export three functions
At 3:03 AM +0100 2001-07-20, Anton Altaparmakov wrote: I do appologize. I didn't realize pine would do this. In pine I can just read the attachment as text and in Eudora it just appears as inlined text without any indication of it being a separate attachment, so I just assumed that it was sent clear text. Obviously not. Stupid mailers. Grr. Eudora does leave you one little clue: At 2:19 AM +0100 2001-07-20, Anton Altaparmakov wrote: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=-559023410-1804928587-995591940=:20239 -- /Jonathan Lundell. - 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://www.tux.org/lkml/
Resend inlined text: [PATCH] Minor cleanup and export three functions
Sorry for confusion. Here goes again, sent with elm, and tested for being
clear text inline and that white space is not mangled.
-
Linus,
Please consider attached patch. It does three things:
- Adds docbook style comments to a very few functions relating to the page
cache (mm/filemap.c) and does very minor clean up on those to keep within
80 character wide lines (only look affected).
- Minor cleanup making the offset/index parameter const in those
functions.
- More importantly, the patch exports the following three functions:
from mm/filemap.c (adding to include/linux/pagemap.h):
__find_page_nolock()
__add_to_page_cache()
from fs/buffer.c (adding to include/linux/fs.h):
create_empty_buffers()
The static keyword is removed, they are added to the indicated header
files as extern or extern inline as appropriate, and they are also added
to kernel/ksyms.c.
These three functions are used by the new NTFS driver which is under
development and in specific in the inode metadata in page cache part. I
have looked at alternatives but they lead to much nastier complications
within the ntfs code. (E.g. due to forcing me to drop the pagecache_lock
if I were to use add_to_page_cache() function instead of
__add_to_page_cache() which would in turn lead to potential race
condition, and anyway dropping the lock to only reacquire it straight
after returning after the function seems very inefficient.)
Any objections to the patch? If not, please apply. Thanks!
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
--- Patch follows this line ---
diff -urN linux-2.4.7-pre8-vanilla/fs/buffer.c
linux-2.4.7-pre8-tng-mrproper/fs/buffer.c
--- linux-2.4.7-pre8-vanilla/fs/buffer.cThu Jul 19 18:53:17 2001
+++ linux-2.4.7-pre8-tng-mrproper/fs/buffer.c Thu Jul 19 20:45:00 2001
@@ -1434,7 +1434,8 @@
return 1;
}
-static void create_empty_buffers(struct page *page, kdev_t dev, unsigned long
blocksize)
+void create_empty_buffers(struct page *page, kdev_t dev,
+ unsigned long blocksize)
{
struct buffer_head *bh, *head, *tail;
diff -urN linux-2.4.7-pre8-vanilla/include/linux/fs.h
linux-2.4.7-pre8-tng-mrproper/include/linux/fs.h
--- linux-2.4.7-pre8-vanilla/include/linux/fs.h Thu Jul 19 18:53:19 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/fs.hThu Jul 19 23:02:10 2001
@@ -1320,6 +1320,8 @@
typedef int (get_block_t)(struct inode*,long,struct buffer_head*,int);
+extern void create_empty_buffers(struct page *, kdev_t, unsigned long);
+
/* Generic buffer handling for block filesystems.. */
extern int block_flushpage(struct page *, unsigned long);
extern int block_symlink(struct inode *, const char *, int);
diff -urN linux-2.4.7-pre8-vanilla/include/linux/pagemap.h
linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h
--- linux-2.4.7-pre8-vanilla/include/linux/pagemap.hTue Jul 3 23:42:57 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h Thu Jul 19 21:08:33
+2001
@@ -60,7 +60,8 @@
* For the time being it will work for struct address_space too (most of
* them sitting inside the inodes). We might want to change it later.
*/
-extern inline unsigned long _page_hashfn(struct address_space * mapping, unsigned
long index)
+extern inline unsigned long _page_hashfn(struct address_space *mapping,
+ const unsigned long index)
{
#define i (((unsigned long) mapping)/(sizeof(struct inode) ~ (sizeof(struct inode)
- 1)))
#define s(x) ((x)+((x)PAGE_HASH_BITS))
@@ -75,6 +76,8 @@
unsigned long offset, struct page **hash);
extern struct page * __find_lock_page (struct address_space * mapping,
unsigned long index, struct page **hash);
+extern inline struct page *__find_page_nolock(struct address_space *mapping,
+ const unsigned long offset, struct page *page);
extern void lock_page(struct page *page);
#define find_lock_page(mapping, index) \
__find_lock_page(mapping, index, page_hash(mapping, index))
@@ -86,8 +89,13 @@
extern void __add_page_to_hash_queue(struct page * page, struct page **p);
-extern void add_to_page_cache(struct page * page, struct address_space *mapping,
unsigned long index);
-extern void add_to_page_cache_locked(struct page * page, struct address_space
*mapping, unsigned long index);
+extern inline void __add_to_page_cache(struct page *page,
+ struct address_space *mapping, const unsigned long offset,
+ struct page **hash);
+extern void add_to_page_cache(struct page *page, struct address_space *mapping,
+ const unsigned long index);
+extern void add_to_page_cache_locked(struct page *page,
+ struct address_space *mapping, const unsigned long index);
extern void
Re: Resend inlined text: [PATCH] Minor cleanup and export three functions
This is clearly not my day for sending emails... Sorry. The attachment was fine on last email but a little misunderstanding between elm and myself resulted in the invention of two non-existent email addresses and put them in the To: field. )-: Just remove them before replying... They are quite obvious: [EMAIL PROTECTED], [EMAIL PROTECTED] Just trying to preempt the flames I am bound to get for that mess up... At least I know how to do it properly next time. (-: Anton -- Nothing succeeds like success. - Alexandre Dumas -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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://www.tux.org/lkml/
Re: Resend inlined text: [PATCH] Minor cleanup and export three functions
At 03:58 20/07/2001, Anton Altaparmakov wrote: This is clearly not my day for sending emails... Sorry. The attachment was fine on last email but a little misunderstanding between elm and myself resulted in the invention of two non-existent email addresses and put them in the To: field. )-: Just remove them before replying... They are quite obvious: [EMAIL PROTECTED], [EMAIL PROTECTED] Just trying to preempt the flames I am bound to get for that mess up... At least I know how to do it properly next time. (-: And I just realized I can't spell Torvalds properly either. Linus, sincerely I apologize. I am going away to hide my head in the sand now... /-: Best regards, Anton -- Nothing succeeds like success. - Alexandre Dumas -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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://www.tux.org/lkml/
