From owner-freebsd-hackers  Mon Jan 26 23:43:43 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id XAA03719
          for hackers-outgoing; Mon, 26 Jan 1998 23:43:43 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03713;
          Mon, 26 Jan 1998 23:43:33 -0800 (PST)
          (envelope-from grog@lemis.com)
Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137])
	by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id RAA20473;
	Tue, 27 Jan 1998 17:57:14 +1030 (CST)
Received: (from grog@localhost)
          by freebie.lemis.com (8.8.8/8.8.7) id RAA12052;
          Tue, 27 Jan 1998 17:57:14 +1030 (CST)
          (envelope-from grog)
Message-ID: <19980127175713.58429@lemis.com>
Date: Tue, 27 Jan 1998 17:57:13 +1030
From: Greg Lehey <grog@lemis.com>
To: dyson@FreeBSD.ORG
Cc: Mike Smith <mike@smith.net.au>, doconnor@cain.gsoft.com.au, joelh@gnu.org,
        dag-erli@ifi.uio.no, hackers@FreeBSD.ORG
Subject: Re: File I/O in kernel land (was: Re: 2nd warning: 2.2.6 BETA begins in 10 days!)
References: <199801270648.RAA01893@word.smith.net.au> <199801270720.CAA00625@dyson.iquest.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <199801270720.CAA00625@dyson.iquest.net>; from John S. Dyson on Tue, Jan 27, 1998 at 02:20:17AM -0500
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk

On Tue, Jan 27, 1998 at 02:20:17AM -0500, John S. Dyson wrote:
> Mike Smith said:
>>
>> As Julian said, see how the code in the kernel handles reading executable
>> images.  It's moderately painful, but definitely the Right Way to do it.
>
> You should refer to the code in -current, because the older stuff had some
> problems.  Also, you can do vn_open, vn_read, vn_write,
> vn_close if you want to.  There are the options to do I/O to/from system
> space.  The only reason (that I know of) that the exec code doesn't use
> the vn_* calls is for efficiency reasons, so lots of stuff is bypassed
> and done slightly VMish as opposed to file I/Oish.
>
> I don't have lots of time to tutor, but what you should be able to do is:
>
> vn_open() to get the vnode.  It will return with a reference to the
> vnode.  That is approx equiv to an open file.  (Take a look at namei
> to figure out how to specify a filename.)
>
> vn_read/vn_write will properly read and write the file, also handling
> file datastructure locking.
>
> vn_close() to loose the file reference.

You also need to look at the uio and iov structures.  Amongst other
things, it describes macros which help make this interface bearable.
There's some stuff on this in part 9 of the manual.  I'm also working
on a document (along with trying to write the *(&*& stuff.  I'd supply
my files, but they deal with block device I/O, which isn't the general
case).

Now who was going to write buf(9)?

> I know that it seems to be complicated, but not really worse than doing
> I/O in user-land on VMS :-).

Or in WNT?

Greg