Re: Trap number: how a system software recognise it?
From: Jan Kandziora (jjj_at_gmx.de)
Date: 03/02/05
- Next message: Kasper Dupont: "Re: How to access ISA memory from user mode"
- Previous message: Kasper Dupont: "Re: Open a pipe with Tclsh rather than sh"
- In reply to: TonY: "Trap number: how a system software recognise it?"
- Next in thread: Kasper Dupont: "Re: Trap number: how a system software recognise it?"
- Reply: Kasper Dupont: "Re: Trap number: how a system software recognise it?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 02 Mar 2005 09:58:16 +0100
TonY schrieb:
>
> PART1
> ----------
> Assume within a C user program there is a read (fid, buf, nbytes)
> procedure call. According to Tanenbaum book, this will call a C-system
>
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----
>
> What about the devices which are recognised without installing device
> drivers, have they a fixed location and trap numbers? Is this
> documented for whoever want to write a device driver?
>
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.
> PART 2
> ----------
> The main CPU initiates the I/O operation by instructing the device
> controller with a high level commands (writing to the device registers
> and so on). Such high level commands are then translated to lower
> instruction by the device controller.
>
> Then it is up to the device
> processor to take these commands and branch to the relevant device
> driver code at the kernel space to perform the low level instructions.
> Upon completion an interrupt will be sent to the CPU to flag
> (hopefully) the completion of the task.
>
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 assigned 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 passed 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
passes execution 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 assigned 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.
>
> So could we deduce that the device processor have *full* access to the
> kernel memory (fill privileges)?
>
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
- Next message: Kasper Dupont: "Re: How to access ISA memory from user mode"
- Previous message: Kasper Dupont: "Re: Open a pipe with Tclsh rather than sh"
- In reply to: TonY: "Trap number: how a system software recognise it?"
- Next in thread: Kasper Dupont: "Re: Trap number: how a system software recognise it?"
- Reply: Kasper Dupont: "Re: Trap number: how a system software recognise it?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
