On Sun, Apr 29, 2001 at 11:04:06PM -0700, Greywolf wrote:
> 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)? */?

well, i think we'd want devopen(dev_t dev, int flags)-- where flags is
a typical set of flags as would be passed to open(2).



> Problems I see are:
> 
> 	- it would have to be a super-user-only call, since there are no
> 	  permissions inherent in a device

I'd go one step further, and say we should make sure it has a view of the
"real" root inode before permitting the call.. (e.g. don't permit in a
chroot'd cage).

> 	- 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.

The f* calls are all built out of fd's.. fdopen() could fill in the FILE
structure nicely.

> 	- Would there even be a stat structure associated with such an fd?
> 	  It'd be interesting filling in values.

It depends if there would need to be.. the correct behavior would have to
be documented..

> # 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.

Mike

-- 
Michael P. Lyle
Chief Technical Officer
Recourse Technologies, Inc.