2

I'm trying to make a system call that will return the inode number of a file, and chose to use the FTS and FTSENT structures, since I found them while searching and they are also used in ls.c (of the usual ls program, which with -i gives us the inode numbers).

To keep things tightly packed, I added the two functions in the bottom of table.c in /usr/src/servers/vfs.

This is the error (for completeness' sake):

table.o: In function 'do_inode_nr':
table.c:(.text+0x1f): undefined reference to __fts_open60
table.c:(.text+0x50): undefined reference to __fts_read60
clang: error: linker command failed with code 1 (use -v for invocation)

I cannot use -v because I'm building with make hdboot from within /usr/src/releasetools.

The code:

//forward declaration of the functions before the table itself
//table and default stuff

//after all this
#include "fts.h"

int do_inode_nr()
{
    FTS* s = fts_open(&m_in.m1_p1, 0, NULL);
    printf("%s", s? "got inode\n" : "failed to get inode\n");
    if(s == NULL) return -1;
    FTSENT* p = fts_read(s);
    printf("%d", p->fts_ino);
    return p->fts_ino;
}

further notes:

Q: Is this a project? Are you trying to get us to do your homework? A: Yes it is a project for a class, but obviously I have already found an answer I am happy with and am asking for help dealing with the linker error, I am not asking for a solution, don't insult me claiming that I am too lazy to solve it on my own (just in case :) )

Q: Why in table.c? A: We are to make a patch with git, but it has been known to be slightly hard to convince to add new files to the patch so I'm sticking to table.c which is anyway included int the patch - what I'm saying is, I know I should generally put new code in separate files etc, but given the fact that I'm not going to do much more, it's really easier this way.

Q: Have I looked at other alternatives? A: I seem to be the only one turning to the FTS struct, I would rather it worked as expected and hand in a mode unique solution than just do what everyone else is doing. Once the grace days start, I'll also try the other way.

Q: Have you looked it up? A: Yup, came up with very little, which I can't say was of any help.

Thank you in advance for any attempt to help.

user3079666
  • 1,159
  • 10
  • 23

1 Answers1

0

This won't work. VFS's job is to transmit I/O requests down to the correct "driver" which will service it. open, and read in your code are ways to perform such requests. But VFS can only handle requests from "user" programs; it cannot call itself. Using ls.c as source to modify VFS was a bad idea.

You need to replace the calls to open and read with the effect they have within VFS, using eat_path and such.

Community
  • 1
  • 1
AntoineL
  • 888
  • 4
  • 25