Sunday, February 22, 2009
ttymon login
Beside getty login, SVR4 also supports another login via ttymon. Typically getty login is used for console and ttymon login is used for terminal. In ttymon login, init fork-exec program sac (sevice access controller). sac fork-exec ttymon when system enters multiuser state. ttymon monitors all terminal ports listed in the configuration file. When user logs in, ttymon fork-exec program login. Note that the parent of login is now ttymon while the parent for getty is init.
getty login
Login in from terminal or modem (remote) connecting via RS232 connection comes from terminal driver in the kernel. Terminal device configuration are defined in /etc/ttys by the administrator. When the system boots, it creates the first process, init (PID=1). init reads /etc/ttys and for each termial devices that allows login, init fork-exec program getty.
getty is run with superuser privilege (UID=0). It open the terminal in RW mode. getty sets file descriptor 0, 1 and 2 to the terminal device driver. It then outputs the login prompt. Once the user enters its userid, getty exec program login to handle the input.
login prompts the user for the password and uses crypt to encrypt the password entered for checking. If the password is invalid, login will exit with code 1 after a few tries. Control passed back to init and it fork-exec the getty again to restart the process. If the password check is successful, login will set up the user environment and changes to the user's ID before it invoke the shell using execl call - ("/bin/sh", "-sh", (char *) 0). The minus sign is a flag to tell all shells that they are being invoked as a login shell. Finally, the login shell reads the start up files (e.g. .profile) before displaying the first prompt for user.
getty is run with superuser privilege (UID=0). It open the terminal in RW mode. getty sets file descriptor 0, 1 and 2 to the terminal device driver. It then outputs the login prompt. Once the user enters its userid, getty exec program login to handle the input.
login prompts the user for the password and uses crypt to encrypt the password entered for checking. If the password is invalid, login will exit with code 1 after a few tries. Control passed back to init and it fork-exec the getty again to restart the process. If the password check is successful, login will set up the user environment and changes to the user's ID before it invoke the shell using execl call - ("/bin/sh", "-sh", (char *) 0). The minus sign is a flag to tell all shells that they are being invoked as a login shell. Finally, the login shell reads the start up files (e.g. .profile) before displaying the first prompt for user.
Sunday, February 15, 2009
Unbuffered I/O and effect of buffer size
Most UNIX I/O can be accomplished by 5 system calls - open, lseek, read, write and close. They are unbuffered I/O calls. Programmer needs to allocate a buffer and pass it as one of the arguments to these I/O functions. If the buffer size picked is small, more I/O read/wrtie calls will have be made to transfer the same amount of data in and out of the program. A small buffer size results in higer CPU utilization (System and User) as well as longer total run time. Using larger buffer size will decrease CPU time. This is an example of trading CPU with memory usage. The CPU improvement will taper off at a certain buffer size beyond which further CPU utilization decrease will not be significant when the number of I/O call has already become quite small.
UNIX standard I/O packages provides a buffered I/O call interface for program. When using these calls, programmer no longer needs to concern with buffer size as it will be taken care by the standard I/O calls.
UNIX standard I/O packages provides a buffered I/O call interface for program. When using these calls, programmer no longer needs to concern with buffer size as it will be taken care by the standard I/O calls.
Subscribe to:
Posts (Atom)