I've been learning more about OpenGL recently, and there's one aspect about retrieving function pointers to the OpenGL function implementations in your local drivers that I can't quite understand (https://learnopengl.com/Getting-started/Creating-a-window):
It is then the task of the developer to retrieve the location of the functions he/she needs and store them in function pointers for later use.
What does it mean to get a function pointer to some memory location in a device driver? Are there any restrictions with doing so? It seems that allowing a user space process to call a kernel space function directly by memory location would not be very safe. Plus, where in the process's virtual address space would the memory location even be?
My understanding is that interfacing with drivers is usually done through system calls. So perhaps instead OpenGL functions are pointers to the system call function + the parameter is made?
If I'm misunderstanding the process, I'd love to learn more about how user space processes can interact with code from drivers.
Your understanding is correct: user space processes should not be able to call a kernel space function directly and interfacing with drivers is done through system calls.
It's (usually) easy to get/create a function pointer to a memory location in the kernel space. In both Linux and MS Windows the kernel is part of the linear address space visible to a process: any good system programming guide should explain where exactly if you are curious. What should happen is that if you call through the function pointer, as soon as the code tries to read or write anything in the kernel space it fails because the code is not executing with kernel privileges.
So the GLAD or whatever loader isn't getting function pointers to the device driver. It is getting function pointers to the OpenGL library (libGL.so, OpenGL32.dll, whatever) functions, which are in user space. These OpenGL library functions in turn make a syscall, which switches the CPU to privileged mode, to the actual device driver code.
But conceptually it's easier to think of this as "calling the device driver" since very often the OpenGL library code is just passing the arguments unchanged through a syscall.