No subject


Wed Dec 17 22:35:13 UTC 2008


and whether init should be making this ioctl for none, some or all of the
processes that it forks off.

> I won't pretend to understand the connection between this system call, the
> console, and the lack of job control.

I searched the web for information on progress groups, controlling ttys and
the like and found one[1] that started off saying something like "Process
groups are one of the features least well understood by UNIX programmers".  
I'm not surprised if you read the some of the manual pages like those for
tcgetattr and getpgrp.  That web page[1] goes on to describe how there are
different (conflicting) APIs for process group control, which also doesn't
help when you're trying to understand them.

I'll try and explain it to the best of my current knowledge (and hope for
corrections and clarifications from others ;-)

All processes belong to exactly one process group.  A progress group can
contain one or more processes.  A progress group is identified by a number
("pgid").

Many process groups may be associated with a single terminal (for example, a
shell might have several processes running started with "xyz &" commands). 
However, the terminal will have one process group which is deemed to be the
foreground process group.  Only processes which are members of the foreground
process group may perform I/O to the terminal device (i.e. through file
descriptors which are connected to the terminal device).  Non-foreground
process groups are signalled with SIGTTIN/SIGTTOU if they attempt I/O.

It is possible to use tcgetpgrp on a file descriptor which is connected to a
terminal to find out what the current foreground pgid of the terminal is. 
This can then be compared with the pgid returned by getpgrp to determine
whether the your process is connected to a terminal AND a member of that
terminal's current foreground process group.  This is the test that ash uses
to determine whether or not to permit job control.  It is calling tcgetpgrp
on stderr's file descriptor and getting back -1/ENOTTY.  Presumably that
means that a serial console does not identify itself as being a TTY then?  

I'm not sure about any of this - I've been trawling through the kernel
sources and I'm not sure I haven't confused myself even more now :-)



[1] http://world.std.com/~jmf/papers/signals/signals.html
[2] http://www.uwsg.iu.edu/hypermail/linux/kernel/0009.1/1285.html

-- 
Stewart Brodie, Senior Software Engineer
Pace Micro Technology PLC
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom         WWW: http://www.pacemicro.com/



More information about the busybox mailing list