so may be its not getxattr, but inode itself is null:
No, the inode is not NULL, it has been allocated in ram at adress 0x4654a0 and most of fields have been initialized. For example: d_inode->i_op->setattr = <ramfs_nommu_setattr> d_inode->i_op->getattr = <simple_getattr>
There are other options like CONFIG_AUDIT_TREE, disable that too. Also make sure that initrd image has the ext2 driver compiled for this kernel.
I am using initramfs support to mount VFS, not init ramdisk (initrd) If I well understand, in my case I have not to deal with precompiled drivers. I only provide a config file to the CONFIG_INITRAMFS_SOURCE option.
If you are using vanilla ext2 fs and CONFIG_EXT2_FS_XATTR is set, then it must be initialized in static inode operations table, look at: ext2_file_inode_operations for files ext2_dir_inode_operations for dir ext2_special_inode_operations for special files ext2_fast_symlink_inode_ operations and ext2_symlink_inode_operations for symlinks all of them are compiled and initialized with generic_getxattr if you compile with CONFIG_EXT2_FS_XATTR.
Indeed, I dug in the source code, I agree with this. Unfortunalety, when debugging, it appears that inode->i_op->getxattr remains null. But I am confused.. for example, what the difference (in the .config file) between "File systems" and "Pseudo filesystems" menus? Because we are speaking about my VFS, so at the moment, the kind of the filesystem is not really important for me. What the difference if I choose ramfs instead of ext2 for example? I have some shadow zones that make me confused.. Thanks for your help.