Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!caen!uflorida!gatech!purdue!spaf
From: spaf@cs.purdue.EDU (Gene Spafford)
Newsgroups: comp.unix.internals
Subject: Re: Wizard-level questions
Message-ID: <13244@medusa.cs.purdue.edu>
Date: 31 Jan 91 06:46:24 GMT
References: <16048@sdcc6.ucsd.edu> <1991Jan26.142403.22812@mp.cs.niu.edu> <3330@unisoft.UUCP>
Sender: news@cs.purdue.EDU
Reply-To: spaf@cs.purdue.edu (Gene Spafford)
Organization: Department of Computer Science, Purdue University
Lines: 28

In article <3330@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes:
>But one I've been wondering about is, why not an istat(dev, ino, statbuf)
>call?

Well, ignoring the question of *why* you would want such a call, it
is not too difficult to write such a beast that root can use.
See, you open the raw device (not the block) associated with the
disk, read in the appropriate inode, and.....you get the idea.

The kernel filesystem is there to provide you some services, to wit:
   * device-independent I/O operations
   * name to location lookup and binding
   * buffered I/O for better performance
   * security checks
   * some consistency control

Mucking with direct i-node numbers, even read-only, violates a couple
of those ideas, so you have to go through the motions yourself.
It isn't all that difficult, but the result is of questionable
usefulness.

Of course, this only works for local disks.  If you are using a remote
file systems for the device, have fun :-)
-- 
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu	phone:  (317) 494-7825