From df04ae29b258b89bbd4991bd862a03ac56430e4e Mon Sep 17 00:00:00 2001 From: Christopher Faylor Date: Sat, 26 Jul 2003 04:53:59 +0000 Subject: * 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. --- winsup/cygwin/ipc.cc | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'winsup/cygwin/ipc.cc') diff --git a/winsup/cygwin/ipc.cc b/winsup/cygwin/ipc.cc index d37f45947..c89b23e21 100644 --- a/winsup/cygwin/ipc.cc +++ b/winsup/cygwin/ipc.cc @@ -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. */ -- cgit v1.2.3