Xref: utzoo comp.bugs.sys5:1486 comp.unix.internals:2102
Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.bugs.sys5,comp.unix.internals
Subject: Re: cfreelist info
Message-ID: <19062@rpp386.cactus.org>
Date: 19 Feb 91 14:28:00 GMT
References: <19050@rpp386.cactus.org> <2022@necisa.ho.necisa.oz.au>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 24
X-Clever-Slogan: Recycle or Die.

In article <2022@necisa.ho.necisa.oz.au> boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes:
>`c_size' contains the size of the cblock data in bytes (ie CLSIZE).

I knew that much - I wanted to know "why".

>The only reason I could think of them doing this is to enable dynamic
>sizing of the cblocks.

This seems to be one of the commonly given reason.  I've not read the
more recent AT&T device driver writer's guides to know what they have
to say.  The XENIX device driver supplement gives 'c_size' as the
buffer size, but isn't specific about cfreelist.c_size, which is
actually a different structure type anyhow ...

Thanks for all of your responses.  My X29 tty driver is doing much
better now, thank you ;-)

And the "crash" command that I posted 3 years ago will be reposted
Real Soon Now with enhancements for figuring some of this stuff out.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"I've never written a device driver, but I have written a device driver manual"
                -- Robert Hartman, IDE Corp.