lkml.org 
[lkml]   [2000]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectFilesystem questions.

Hi all,

I've spent a while this evening hacking on the 2.3.99 AFFS driver.
I've rewritten the file_write routines, and got it into a state where
it compiles, which is a start, but now I have unsolved symbols when I
try to insert the module.

__divdi3
__moddi3

At first I thought these were gcc builtins. So I compiled file.c with
-fno-builtin, after a minor complaint about 'abs' being undefined
in linux/fs.h, so I did this[1]..

--- fs.h~ Tue Mar 28 00:01:36 2000
+++ fs.h Tue Mar 28 00:01:11 2000
@@ -789,6 +789,8 @@
return 0;
}

+#define ABS(a) ((a)<0 ? -(a) : (a))
+
extern inline int locks_verify_truncate(struct inode *inode,
struct file *filp,
loff_t size)
@@ -797,7 +799,7 @@
return locks_mandatory_area(
FLOCK_VERIFY_WRITE, inode, filp,
size < inode->i_size ? size : inode->i_size,
- abs(inode->i_size - size)
+ ABS (inode->i_size - size)
);
return 0;
}

It compiled, but still the same result.

I grepped the kernel source tree for these functions, but they only
showed up in the sparc, arm & IA64 trees.

Why is i386 trying to use these functions?
Where are they being referenced ?

If anyone can shed any light on this, I'll probably be able to get
affs usable again..


[1] Is this a good idea btw?
Should we be relying on functions outside the kernel source?
I've not checked the above function, it compiles, but I don't
guarantee it performs the same as the original code.

regards,

--
Dave.


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

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