Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!spdcc!dyer
From: dyer@spdcc.COM (Steve Dyer)
Newsgroups: comp.unix.xenix
Subject: Re: XENIX.. speed up of /dev/port ..  (Getting the INODE)
Keywords: inode xenix port
Message-ID: <2371@spdcc.SPDCC.COM>
Date: 6 Jan 89 23:42:26 GMT
References: <6552@pogo.GPID.TEK.COM>
Reply-To: dyer@ursa-major.spdcc.COM (Steve Dyer)
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 26

In article <6552@pogo.GPID.TEK.COM> curtj@pogo.GPID.TEK.COM (Curt ) writes:
>I have 1.2 Meg, to send down through an I/O port.  Since I have to to
>an 'lseek' every time I wish to send a byte down to a specific port
>address, it takes an astronomical amount of time to send the data.
>Is there any way to cause READ/WRITE to NOT update the file pointer address
>when you execute them.  If not, HOW DO I GET HOLD OF THE i-node so that I
>can reset the file pointer to the proper address every time I issue a
>READ/WRITE.  I am trying to cut down the system call overhead.

Sounds like you're ready to graduate to a REAL device driver.
Believe me, you shouldn't be too concerned by the time being consumed
by the extra lseeks, which are very fast, anyway; the byte-at-a-time
paradigm is burning you as badly.  There really isn't a way to
"get hold of the i-node" (file pointer, actually) from userspace
to make the lseeks unnecessary; at least, no way more efficient than
just doing the lseeks.

If your device is a simple IO port with no capability of generating an
interrupt, a device driver is VERY simple (hell, it's simple anyway.)
The SCO documentation has a chapter on writing device drivers, with
examples for boilerplate.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu