Trap number: how a system software recognise it 3081

TonY schrieb: Tanenbaum wrote indeed good books about operating systems, but they describe MINIX, not Linux. You are pretty much in the wrong discussion group here.

----Schnipp---- As far as I know, MINIX has no concept of "device recognition". MINIX has very few persons contributing to it, too, so it would be easy for them to discuss how to implement a new device driver - not so much documentation needed.

As MINIX is a operating system solely for educational purposes, a further development is unlikely. Even Prof. Tanenbaum is working on other projects now, I think.

If you mix up MINIX and Linux further, I would suspect you are a SCO goon who wants to construct some legal connection between them. ^^ There are no traces of MINIX (aside from MINIX filesystem support) left in Linux - give up.

You are mixing up a lot of things here. Please forget all know think you know about this topic.

There are several levels of program code involved whenever a user application wants to talk to a device, e.g. a serial port.

1. User program issues read(fd,...) libc function to read some bytes from file descriptor fd, which was buttigned to a certain serial port by a previous fd=open("-dev-ttyS0",...) call. 2. libc has code which calls the kernel task gate-trap. The code for "read call" and its parameters are pbutted to the kernel. 3. The main CPU reacts to the trap and switches to "kernel mode". 4. In kernel mode, the task gate code detects the code for "read call" and pbuttes end to the global "read call" function. 5. This function checks the "fd" argument of the call. It looks into the kernel's file descriptor table for the process which issued the trap. Each file descriptor in the table is buttigned to a file on the disk, or a special file. In our case, it is a special file, representing the first serial port. 6. From the file inode in the file system, the kernel gets the "major" and "minor number" of the device. Historically, the "major number" selects the device driver in UNIX, the minor number is a number internally used by a certain device driver to distinguish devices handled by the same driver, e.g. 1st, 2nd, 3rd serial port. 7. The driver's "read call" function is called, giving the minor device number as a hint which serial port to read. 8. The driver now "programs" the devices "CPU" (e.g. a 16550 serial port chip), and receives some data. 9. The data is given back to the global "real call" function of the kernel, which returns it through the task gate. 10. We are back in user mode and our program got the serial data.

The "device processor" can control anything in the computer the other hardware allows it to do. t is a processor, anyways, and such concepts as "kernel memory" just don't exist in hardware.

If the "device processor" does something wrong, it's certain the computer will be damaged - even in our days, computers are made of electronics, which means electric current is flowing. You know what is happening if you short circuit the connectors of a car battery, don't you? Computers are no different. -- Jan