From owner-freebsd-current  Wed Apr  9 05:18:17 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA15869
          for current-outgoing; Wed, 9 Apr 1997 05:18:17 -0700 (PDT)
Received: from spinner.DIALix.COM (root@spinner.dialix.com [192.203.228.67])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA15857
          for <current@freebsd.org>; Wed, 9 Apr 1997 05:18:12 -0700 (PDT)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.5/8.8.5) with ESMTP id UAA17638;
          Wed, 9 Apr 1997 20:17:56 +0800 (WST)
Message-Id: <199704091217.UAA17638@spinner.DIALix.COM>
X-Mailer: exmh version 2.0gamma 1/27/96
To: shocking@mailbox.uq.edu.au
cc: current@freebsd.org
Subject: Re: POLL & the Single FreeBSD'r 
In-reply-to: Your message of "Wed, 09 Apr 1997 20:20:06 +1000."
             <199704091020.UAA00811@mailbox.uq.edu.au> 
Date: Wed, 09 Apr 1997 20:17:56 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

shocking@mailbox.uq.edu.au wrote:
> 
> 	Pete, if you can figure out a way to have it co-exist with old LKMs 
> for devices that have the select interface only (I'm thinking here of the OSS
> LKM I just purchased), then, in the words of that ad which the HeavensGate 
> people acted on,
> 
> 		Just Do It.

Yeah, well, that's the thing isn't it...  Trying to maintain binary 
compatability with an older release... :-]  The select handler takes an 
"int" arg, the poll handler takes an "int *" arg.  Extending the cdevsw 
vector is painful..  Still, I guess there's the possibility of doing 
something cute within devsw_register(), or have a devsw_register2 with 
some #defines so that the old devsw_register takes an "ocdevsw" table and 
pads it, the new one takes the extended table, and compile time checking 
sorts out the mess.  ie: something similar to the getvfsbyname() and 
mount() tweaks.

I guess the question becomes, what else is likely to break from a kernel
binary compatability perspective soon anyway?  Is the LKM likely to "know" 
about offsets in struct proc etc?  These change regularly..

> 	Stephen

Cheers,
-Peter