Re: kernel panic in inode_lookup

On Thu, May 30, 2002 at 07:24:02PM +0200, Jan Hudec wrote:

On Thu, May 30, 2002 at 01:45:22PM -0300, Marcos Dione wrote:

It is'n clear to me where you get the inode number, ie. if the function
you call just allocates next free number or somehow compute it from the
request. Anyway, in network filesystem calls to iget DONT make much
sense. iget is method for looking up inodes by some key. It goe through
the inode hash and then fall back to read_inode to create it. If your
inode numer happens to be a sane lookup key, you have to implement the
read_inode method (it should create new inode using get_new_inode or
get_empty_inode and initialize it). If your ino is just a unique key,
then you know you will end up creating a new inode, so go ahead and call
get_new_inode directly.

  ok. first, the ino is get from the real filesystem, in the server.
second, in read_super I call new_inode. I guess its better to add some
context.

  I can mount my file system, and even read the root inode. I can even
list the contents of my root dir. in read_super, for returning the
root inode, I call new_inode (sb), where sb is the superblock
structure I'm filling. I think something must be wrong, because then
inode->i_sb->s_op function pointers are all NULL ATM of calling
inode_lookup. I mean, why these two line, taken from my read_super, are wrong?:

      sb->s_op= &ogt_super_operations;
      inode= new_inode (sb);

  after the second call, inode->i_sb->s_op functions should be ok, but
they're NULL! the ogt_super_opertions... shit! could you believe it?
it was a wrong definition of the sb's ops! shite, sometimes I hate C
so much... ok, I learn.

  zanx for your help, anyways.