From owner-freebsd-arch  Mon Jun 26 14:36: 2 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id 19C1837B932; Mon, 26 Jun 2000 14:35:56 -0700 (PDT)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e5QLZtk02770;
	Mon, 26 Jun 2000 14:35:55 -0700 (PDT)
Date: Mon, 26 Jun 2000 14:35:55 -0700
From: Alfred Perlstein <bright@wintelcom.net>
To: Adrian Chadd <adrian@freebsd.org>
Cc: arch@freebsd.org
Subject: Re: dynamic filetypes.  please comment.
Message-ID: <20000626143555.C275@fw.wintelcom.net>
References: <20000626142428.A275@fw.wintelcom.net> <20000626233203.Y36017@zoe.bastard.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20000626233203.Y36017@zoe.bastard.co.uk>; from adrian@freebsd.org on Mon, Jun 26, 2000 at 11:32:03PM +0200
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Adrian Chadd <adrian@freebsd.org> [000626 14:32] wrote:
> On Mon, Jun 26, 2000, Alfred Perlstein wrote:
> > In order to have a kld add a new filetype (DTYPE_VNODE, DTYPE_PIPE,
> > etc.) it needs to generate a unique number.
> > 
> > My inclination is to just add a DTYPE_MAX(*) and provide a function
> > for the kld initializers to call "short getnewdtype(void)" which
> > returns the next available number.  This does limit us to about
> > 32764 module driver loads before getnewdtype will return -1 (error).
> > 
> > This idea leads us to a generic api for seqeunce number generation
> > that we can use when a subsystem needs an increasing unique number,
> > the api would look something like:
> > 
> >    (void)sequence_register("filetypes", starting_number);
> >    mynum = sequence_next("filetypes"); /* to be used for f_type */
> 
> The debug gods might like:
> 
> mynum = sequence_next("filetypes", "DTYPE_FOO", "A foo-type file");

Yes, the only problem is that it requires storage for each number.

I think that the correct thing to do is provide both APIs, one
requiring storage but providing nicer debugging capabilities along
with number recycling and another with just a straight-up sequence
which fails once a wrap needs to happen.

-Alfred


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message