Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!unisoft!greywolf
From: greywolf@unisoft.UUCP (The Grey Wolf)
Newsgroups: comp.unix.wizards
Subject: Re: Wizard-level questions
Message-ID: <3330@unisoft.UUCP>
Date: 30 Jan 91 03:12:23 GMT
References: <16048@sdcc6.ucsd.edu> <1991Jan26.142403.22812@mp.cs.niu.edu>
Reply-To: greywolf@unisoft.UUCP (The Grey Wolf)
Organization: Foo Bar and Grill
Lines: 39

In article <1991Jan26.142403.22812@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes:
>>[1] Can you access a file by its i-node number?  Something like
>>	(for C code) FILE *iopen (int inode, char *mode) ?
>
> I hope not.  Otherwise permissions on directories wouldn't do much.  I
>do think the system design would have been cleaner if you only accessed
>by i-node number, and mapping filename to inode was done outside the kernel.
>But I doubt that I have many supporters in this "keep the kernel small" view.

Perhaps iopen is, indeed, something of a farce (this is a thinly disguised
understatement!).

But one I've been wondering about is, why not an istat(dev, ino, statbuf)
call?

It's been argued that getting statistics about a certain inode would be
insecure, but I fail to see the logic on this one.  Of course, it might
not be too useful, but I bet there are some times where it might be.

Also, I think there might be some usefulness in having an iname(dev,ino)
system call (restricted to the super-user).

The idea of dealing with inode numbers outside the kernel might not be
such a horrible idea.  I believe this is partly the philosophy behind
the inode_pagedaemon in MACH (I vaguely recall seeing something like this
on a Mach machine we have here -- the term might be wrong).


>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
>  Northern Illinois Univ.
>  DeKalb, IL 60115                                   +1-815-753-6940


-- 
thought:  I ain't so damb dumn!
war: Invalid argument
...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf