Date: Tue, 27 Jan 1998 02:20:17 -0500 (EST) From: "John S. Dyson" <dyson@FreeBSD.ORG> To: mike@smith.net.au (Mike Smith) Cc: doconnor@cain.gsoft.com.au, joelh@gnu.org, mike@smith.net.au, 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!) Message-ID: <199801270720.CAA00625@dyson.iquest.net> In-Reply-To: <199801270648.RAA01893@word.smith.net.au> from Mike Smith at "Jan 27, 98 05:18:56 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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. I know that it seems to be complicated, but not really worse than doing I/O in user-land on VMS :-). -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801270720.CAA00625>