Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rutgers!cbmvax!grr
From: grr@cbmvax.commodore.com (George Robbins)
Newsgroups: comp.unix.ultrix
Subject: Re: DEVIOCGET question
Keywords: Ultrix, UNIBUS, device driver, DEVIOCGET, ioctl
Message-ID: <10349@cbmvax.commodore.com>
Date: 26 Mar 90 09:47:02 GMT
References: <2772@lll-lcc.UUCP>
Reply-To: grr@cbmvax (George Robbins)
Organization: Commodore, West Chester, PA
Lines: 31

In article <2772@lll-lcc.UUCP> rmark@lll-lcc.UUCP (Richard Mark) writes:
> 
> What routines or what actions cause an ioctl(DEVIOCGET) call?
> What devices need to handle an ioctl(DEVIOCGET) call?

Did you get any answers yet?  If not, you can take adb and take a whack at
one of the simpler drivers.  I've seen the DEVIOCGET stuff in passing, but
didn't analyze it that closely.  Seem to involve stuffing data into a
structure, so there's probably a header file involved somewhere.

> And now some more questions:
> Is this specific to a certain version of Ultrix?

I think it showed up in 3.x, this about the time dump started being able
to figure out whether a tape drive was at 1600 or 6250bpi...

> Where can I find out what values I should put in the devget struct?

/usr/include/sys/devio.h

> Where is any of this documented?

ha...DEC seems to love making various changes to Ultrix that move it farther
from 4.2BSD compatibility and not documenting any of the details.  I guess if
you spring for a source license it's obvious, but you shouldn't need a source
license for drivers and syscalls...

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)