I am working on a project where I have to implement a handler for several functions, all of which have a number associated with them. The number that they are associated with is how the different functions are called. Knowing this I want to be able to group them into an array using the number as the index to the functions. The problem is, arrays need to have the same type of elements inside of them right? so how can I place these functions into an array?
Here is how the functions are numbered:
enum
{
SYS_HALT, /* Halt the operating system. */
SYS_EXIT, /* Terminate this process. */
SYS_EXEC, /* Start another process. */
SYS_WAIT, /* Wait for a child process to die. */
SYS_CREATE, /* Create a file. */
SYS_REMOVE, /* Delete a file. */
SYS_OPEN, /* Open a file. */
SYS_FILESIZE, /* Obtain a file's size. */
SYS_READ, /* Read from a file. */
SYS_WRITE, /* Write to a file. */
SYS_SEEK, /* Change position in a file. */
SYS_TELL, /* Report current position in a file. */
SYS_CLOSE, /* Close a file. */
};
And here is the list of function prototypes:
void halt (void) NO_RETURN;
void exit (int status) NO_RETURN;
pid_t exec (const char *file);
int wait (pid_t);
bool create (const char *file, unsigned initial_size);
bool remove (const char *file);
int open (const char *file);
int filesize (int fd);
int read (int fd, void *buffer, unsigned length);
int write (int fd, const void *buffer, unsigned length);
void seek (int fd, unsigned position);
unsigned tell (int fd);
void close (int fd);
Main question
Is there an easy way to put all of the functions into an array or other data structure in C?
Any help would be most appreciated, this is for a school project, so a small example or link would be very useful, but I’d like to create the solution myself.
Thanks
Edit: What I’d like to be able to do
I want to be able to define some array and store a pointer to the functions at the indexes of the enum ordinal numbers.
//I don't know how to handle the type here
<some_type> system_call_arr[128];
system_call_arr[SYS_HALT] = halt;
system_call_arr[SYS_EXIT] = exit;
system_call_arr[SYS_EXEC] = exec;
// and so on....
Edit 2
Since Ben said all of the arguments would fit into a 32 bit argument, couldn’t I define something like this:
typedef int (*sys_func) (uint32_t, uint32_t, uint32_t);
sys_func syscall_array[128];
syscall_array[SYS_HALT] = (sys_func)halt;
//etc....
Is something like this good practice?
The classic UNIX way to do this is to give all of those functions the same signature (say
int sys_func(struct args *a)and then put those all into a function array. When you marshal arguments for the calls you just put them in asarg1,arg2, etc all instruct argsand each syscall uses them differently. Or you can alias a special structure on top of it to give them meaningful names.In your edit you ask, “Is something like this good practice?” I gave my answer in the context of your question, which appears to be the implementation of a simple operating system kernel. Operating systems get to cheat in ways that normal applications never should. It can use assumptions about word size (e.g. that everything is 32-bit, as in ILP-32) and know things about the ABI because implementing these things is part of the operating system’s job. If your OS is portable to other platforms it will compile in different variants of things like
syscallto handle these cases.Why did I suggest
struct argsrather than your method? Because in an operating system you will have a few layers between the user making the syscall and the actual code running from your function pointer table. If you pass these arguments explicitly through each layer you are going to copy them several times. If the first layer can simply provide a pointer that sort of “jumps” the arguments over the intermediate functions. If you’re dealing with an ABI where the calling convention is to push arguments on the stack, you can avoid copying the arguments altogether and just take an appropriate stack address as the args.You can find discussions of this and pretty much every other aspect of operating system design in The Design and Implementation of the 4.4 BSD Operating System by McKusick et. al. If you can find the older 4.3 version it’s actually a fairly slim volume and still entirely relevant to what you’re working on.