From owner-freebsd-hackers  Thu Dec 18 12:08:54 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA18539
          for hackers-outgoing; Thu, 18 Dec 1997 12:08:54 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18519
          for <freebsd-hackers@FreeBSD.ORG>; Thu, 18 Dec 1997 12:08:46 -0800 (PST)
          (envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
	by smtp02.primenet.com (8.8.8/8.8.8) id NAA20835;
	Thu, 18 Dec 1997 13:08:45 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
 via SMTP by smtp02.primenet.com, id smtpd020815; Thu Dec 18 13:08:41 1997
Received: (from tlambert@localhost)
	by usr05.primenet.com (8.8.5/8.8.5) id NAA13665;
	Thu, 18 Dec 1997 13:08:40 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199712182008.NAA13665@usr05.primenet.com>
Subject: Re: converting drivers to dynamic memory...
To: avalon@coombs.anu.edu.au (Darren Reed)
Date: Thu, 18 Dec 1997 20:08:39 +0000 (GMT)
Cc: gurney_j@resnet.uoregon.edu, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199712181327.FAA17836@hub.freebsd.org> from "Darren Reed" at Dec 19, 97 00:23:04 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Why isn't it ok to just free/allocate and the memory when it is (un)loaded ?
> 
> If, I load a device like BPF and tell it I want "NBPF" to be 4, then what
> else besides the BPF driver needs to know that NBPF is 4 ?  (I hope I've
> picked a very simple case :).  What else cares about those buffers ?

There's a fundamental flaw here: that 4 should be anything other than
a soft limit.

The BPF is one of those devices, like pty's or the tun or vn devices,
that is best modelled with a cloning interface.


Initially, I would think you would do something like:

static void *contexts[ NBPFILTER];

fake_bpf_device_op( minor, ...)
{
	return real_bpf_device_op( contexts[ minor], ...);
}

This should make the transition relatively painless.

There would probably need to be a new function for instancing in
the bpf_cdevsw entry, which would be called to instance into the
static contexts value appropriate for the device being referenced,
and a reflexive one for destroying those same contexts.

But this would let you change one device at a time fairly trivially,
and, assuming a recompile an placement of the create/delet at the
end of the struct cdevsw, the values would default to NULL for all
unconverted devices.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.