From owner-freebsd-hackers Sat Oct 11 17:00:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA17913 for hackers-outgoing; Sat, 11 Oct 1997 17:00:00 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA17908 for ; Sat, 11 Oct 1997 16:59:56 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA11116; Sat, 11 Oct 1997 16:59:53 -0700 (MST) From: Terry Lambert Message-Id: <199710112359.QAA11116@usr07.primenet.com> Subject: Re: Is this a bug, or just a feature. To: mdean@best.com (mdean) Date: Sat, 11 Oct 1997 23:59:53 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "mdean" at Oct 11, 97 03:54:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Sorry, I was confused I meant > open ("/dev/fd0", O_RDWR|O_WRONLY, 0); > which gives a valid descriptor when executed(and a disk is in the drive) Yes. A descriptor with a flag value of "1" (0x0002|0x0001) == 3... and a file flags value of 4. I don't understand how this could be "caught", since the value of manifest constant arithmatic is constant, and therefore computed at compile time. The point of these values is historical compatability. Many older programs do not use defined manifest values, and instead use constant 0, 1, or 2. Once in the open code in the kernel, the FFLAGS() macro is called on the value. The point of masking at 3 is that the values 0, 1, 2 won't overflow two bits if you add one: the become 1, 2, and 3. The correspond to FREAD, FWRITE, and FREAD|FWRITE, respectively. If you give a constant value of 3, then you overflow to 4. Basically, O_NONBLOCK. > O_RDWR+O_WRONLY = O_ACCMODE which I am at least using to mask the oflags > and running the remaining bits through a switch statement checking for > O_RDONLY , O_RDWR, O_WRONLY (for this particular device these actually > matter, I am using them to determine the direction of the port for some > control regs) so at the end of the switch i have a default: return (EPERM); > since having O_RDONLY and O_RDWR set at the same time is meaningless (they > are mutually exclusive for me). I was just suprised this isn't caught > before it gets passed to the driver. Because this is effectively a lame bit encoding for open modes to bits 0 and 1 of the flags, I suppose you could mask the value and check for a constant 3, and fail the open. This seems to be overkill to me, since you are not allowed to pass in any of O_RDONLY, O_WRONLY, and O_RDWR combinations by definition of the interface. In your driver, you will be using FREAD/FWRITE bit tests, anyway. The worst effect this should possibly have is badly coded programs that violate the interface definition will send down "O_NONBLOCK" for file flags and set neither FREAD or FWRITE (which you can detect by anding flags with three to test for non-zero). > > > Shouldn't it be an error to call open("/dev/fd0", RD_ONLY|WR_ONLY,0)? You mean "to pass a 3 as the flags value to open"? I don't think it's very useful, but it's not an error, I don't think. I suppose you could still use the fd for an fchdir, in fact. I could see passing a 3 to get a 4 and using an fcntl to unset non-blocking I/O... there could be a number of reasons you'd want a decriptor that referenced an object, yet could not be read or written. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.