* exceptions.cc (ctrl_c_handler): Send SIGHUP when events occur only if there

is a tty associated with the process.  Send SIGHUP on CTRL_LOGOFF_EVENT.
* fhandler_tty.cc (fhandler_tty_slave::open): Adjust console open handle
counter regardless of whether this is a pty or tty.
(fhandler_tty_slave::open): Ditto.
(fhandler_tty_slave::dup): Ditto.
(fhandler_tty_common::set_close_on_exec): Ditto.
(fhandler_tty_master::init_console): Decrement console open handle counter
after init since it will now be handled by all tty open.
* syscalls.cc (setsid): Rework debugging output slightly.
This commit is contained in:
Christopher Faylor
2003-07-26 04:53:59 +00:00
parent ddb6762155
commit df04ae29b2
14 changed files with 231 additions and 223 deletions

View File

@@ -35,45 +35,45 @@ ftok (const char *path, int id)
We will have to alias; leaving open the possibility that the same
key will be returned for multiple files. This possibility exists
also on Linux; the question is, how to minimize this possibility.
How to solve? Well, based on C. Vinschen's research, the nFileIndex*
words vary as follows, on a partition with > 110,000 files
nFileIndexHigh: 564 values between 0x00010000 -- 0xffff0000
nFileIndexLow : 103812 values between 0x00000000 -- 0x0003ffff
R. Collins suggests that these may represent a tree path,
R. Collins suggests that these may represent a tree path,
and that it would require ~2.9M files to force the tree depth
to increase and reveal more bit usage.
Implementation details: dev_t is 32bits, but is formed by
device(32bits) << 16 | unit(32bits)
device(32bits) << 16 | unit(32bits)
But device is ACTUALLY == status & FH_DEVMASK, where FH_DEVMASK
is 0x00000fff --> 12 bits
As it happens, the maximum number of devices is actually
As it happens, the maximum number of devices is actually
FH_NDEV, not FH_DEVMASK, where FH_NDEV is currently 0x0000001d.
However, FH_NDEV grows as new device types are added. So
currently the device number needs 5 bits, but later? Let's
take a cue from Linux, and use the lower 8 bits (instead of the
lower 12 or 16) for the device (major?) number.
Similarly, while 'units' is an int (32bits), it is unclear
how many of these are significant. For most devices, it seems that
'units' is equivalent to 'minor'. For FH_TAPE, it's obvious that
only 8 bits are important. However, for FH_SOCKET...it might be
as high as 16 significant bits.
Let's assume that we only need 8 bits from device (major) and
only 8 bits from unit (minor). (On linux, only 8 bits of minor
are used, and none from major).
---> so, we only need 0x00ff00ff (16 bits) of dev_t
---> we MUST have all 8 bits of id.
---> So, we only have 64 - 8 - 16 = 40 bits for ino_t. But, we
need 0xffff0000 for nFileIndexHigh and 0x0003ffff for nFileIndexLow
minimum, or 16 + 18 = 34 bits. Lucky us - we have 6 more bits
to distribute.
For lack of a better idea, we'll allocate 2 of the extra bits to
nFileIndexHigh and 4 to nFileIndexLow. */