I know that the inode points to the actual disk blocks in the case of the normal file system. But what does it point to in the case of .... say .... the terminal device file. Does it point to the terminal device driver?
One thing you should understand is that the on-disk inode structure is rarely identical to the in-memory inode structure.
What data is stored in an on-disk inode depends on the filesystem. But yes, it will almost invariably have direct and/or indirect pointers to the disk blocks storing the file contents. (With some filesystems, tiny files might have their contents stored directly in the inode.)
What data is stored in an in-memory inode depends on the OS kernel. Generally, for filesystems which are backed by disk, UNIX kernels do not attempt to keep an in-memory inode for every file on the disk, because disks can be huge and might store a very large number of files. In such cases, the kernel would generally keep a cache of in-memory inodes for recently accessed files. If a user process issues a system call relating to some file whose inode is not in the cache, then the OS will have to read the on-disk metadata and construct an in-memory inode for it.
For filesystems which are not backed by some kind of persistent storage, it's possible that an in-memory inode might be kept around for every file all the time. In any case, this depends on the filesystem-specific code in the kernel. If it doesn't keep in-memory inodes for all files, it has to be able to construct them on demand when some user process wants to open a file.
Now more directly to what you asked:
You can see Linux's
struct inode here:
This is the in-memory structure used to represent an inode for any file, from any file system, inside the Linux kernel. Of course, not all the fields will be used in all cases. You can see that the last member is a 'private' pointer, which individual filesystems can use to store any filesystem-specific data.
Looking at the list of fields, I see a count of blocks there, but nothing like direct or indirect block pointers. I guess that for 'normal' filesystems, those are probably kept in the 'private' data.
Does this answer your question? To summarize, your answer is: it depends. What data is stored in an on-disk inode structure is completely dependent on the filesystem, but basically, it is whatever the filesystem needs in order to keep track of what it needs to know about a file. What data is stored in an in-memory inode structure is completely dependent on the OS kernel. If it includes things like block pointers, then presumably those would be left blank for files which aren't backed by disk blocks, like the terminal device file which you mentioned.
The example of Linux shows that the generic in-memory inode structure may not include any block pointers. But it may make provision for each filesystem to keep some of its own private data there, which might include block pointers.
Of course this depends on the file system, but in traditional UNIX filesystems a device node contains a type indicator (block or character device) and a major and minor number. In the kernel, the major number is used to select the driver (actually a table of function pointers for the various operations) and the minor number is passed as an argument to each call. Depending on the driver, it may encode drive and partition numbers for disks, or the serial line number if several ttys are connected to a machine.