리눅스 링킹

커널의 변수도 당연히 직접적인 접근할 수 없습니다.
linking을 하지 않으므로 당연히 불가능합니다.
mdelay() 자체는 macro이지만 그 macro를 계속 따라가다 보면 결국은 커널 변수에 대한 접근 혹은 커널 함수를 부르게 될 겁니다.
따라서 mdelay() 호출은 불가능합니다.

system call은 linking으로 연결되지 않습니다.
예를 들어 system call인 read의 구현은 kernel source 상에 fs/read_write.c에 sys_read()라는 함수로 되어 있습니다.
user는 read system call을 glibc 내부의 함수 read()를 불러서 수행하게 됩니다.
glibc 내부의 read()라는 함수의 내용은 단순히 system call instruction(architercture에 따라서 software interrupt나 trap으로도 불리움)을 수행하는 것입니다.

user가 read()함수를 부르면 CPU에서는 software적인 interrupt가 발생하고 exception vector로 점프합니다.(당연히 CPU는 kernel모드로 바뀝니다.)
exception vector(kernel의 내부)에 있는 코드가 어떤 exception인지 찾아내고 어떤 종류의 system call인지 찾아서 결국은 sys_read()함수를 호출하게 됩니다.

결국 user의 코드는 glibc의 read()라는 함수와 linking되는 것이고 kernel의 sys_read()함수와 linking되는 것이 아닙니다.

user가 kernel의 변수와 함수를 마음대로 참조할 수 있게 되면 악의적인 user가 시스템을 자기 마음대로 바꿀 수 있을 겁니다.
그 user가 설혹 root라고 하더라도 마음대로 할 수 있도록 하면 안됩니다..
(사실 root는 마음대로 할 수 있습니다. root는 가장 간단한 방법으로 kernel을 재설치해도 되고, kernel memory를 직접 접근할 수도 있습니다.)
어느 정도의 protection이 존재해야 합니다.
반면에 user(특히 root)는 kernel의 특정 부분에 대해서 정보를 읽어오거나 정보를 줄 수 있어야 합니다.
그 방법을 proc filesystem, system call, device driver를 이용하는 방법으로 제한하고 있습니다.
쿨럭...