On Sun, 29 Apr 2001, Michael Lyle wrote:

# On Sun, Apr 29, 2001 at 02:25:21PM -0700, Charles M. Hannum wrote:
# > I actually did this years ago.
# >
# > The problem is that every transition between single and multi-user mode
# > requires the console device to be close(2)d, open(2)ed and revoke(2)ed,
# > so at best it helps you through single-user and then you lose anyway.
# > Plus, in anything other than a diskless environment, if your /dev is
# > toast you can't upgrade / to r/w to fix it.  So it didn't seem like
# > much of a gain, and I punted.
#
# Ah-- that's a good point.  That seems like to me another reason why it
# might be desirable to be able to open() arbitrary devices without
# necessarily having to have an inode for them.

At the risk of sounding REALLY, really stewpid, could we implement a
devopen(dev_t dev, filemode_t fmode) /* or should that be
devopen(dev_t *dev, filemode_t *fmode)? */?

NOTE: filemode is the operation mode, not a file (really inode) creation
mode.

Problems I see are:

	- it would have to be a super-user-only call, since there are no
	  permissions inherent in a device.
	- The file descriptor returned by devopen() would be useless passed
	  to anything other than read(), write(), ioctl() or close();
	  in particular any of the f*() calls which do inode operations
	  would be problematic (how would any of the meaningful fields be
	  filled in?).  I was going to say i had my doubts about ioctl(),
	  but they seem to operate dependent on the mode in which the open()
	  occurred, rather than on any status information.
	- Would there even be a stat structure associated with such an fd?
	  It'd be interesting filling in values.

"But other than that..." :-)

I didn't suggest an alternate fd structure for this because it _needs_ to
be interoperable with read(), write(), ioctl() and close().

# Mike
				--*greywolf;
--
If anyone requests a reason as to why Windows NT is inferior to UNIX,
refer them to the process scheduler, for starters.  Of course, users
don't care, and programmers try not to, even though they both should.
If that fails, reiterate that remote administration and control of a
node is a *good* thing, especially if network security is concerned.