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> In-Reply-To: <20000626233203.Y36017@zoe.bastard.co.uk>; from adrian@freebsd.org on Mon, Jun 26, 2000 at 11:32:03PM %2B0200 References: <20000626142428.A275@fw.wintelcom.net> <20000626233203.Y36017@zoe.bastard.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000626143555.C275>