Hi Darren,
        There's another issue with this change. With some open
type(parameter otyp), prefixopen entry will be called once for each
sys_open system call, and prefixclose entry may only be called for
the last sys_close system call when open count changes from
non-zero to zero. So how to ensure that all contexts allocated in open()
will be freed in close()?
        Thanks!

Darren Reed <> wrote:
> With PSARC/2008/755, the topic of "soft state" data association with
> a device was raised. In the case log, there's discussion of whether
> what is being stored is actually "soft state". I'll agree that soft
> state should be per instance of a device but there's still a problem
> here that we need to solve more genericly...
> 
> And that is allowing devices, especially those that want to be
> CLONE_DEV devices, to store some per-open context, somewhere.
> 
> At present this is left up to the device driver writer, so using
> mod_hash or similar with the minor number as a key is an easy
> solution. But that is rather imposing...
> 
> What I'd like to suggest is that we consider expanding the entry
> points for regular device drivers to allow for context to be created
> in open(9e), passed back in with all of the other entry points (read,
> write, strategy, etc) and require the driver to clear it in close(9e).
> 
> This would change function prototypes to be something like:
> 
> int prefixopen(dev_t *devp, int flag, int otyp, cred_t *cred_p, void
> **ctxp);
> int prefixread(dev_t dev, struct uio *uio_p, cred_t *cred_p, void
> *ctx); int prefixclose(dev_t dev, int flag, int otyp, cred_t *cred_p,
> void **ctxp); 
> 
> and so forth.
> 
> For existing drivers, not changing "ctxp" would result in NULL being
> passed into the driver as the "ctx" pointer.
> 
> Thoughts?
> Comments?
> Flames?
> 
> Darren
> 
> _______________________________________________
> opensolaris-code mailing list
> opensolaris-code@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Liu Jiang (Gerry)
OpenSolaris, OTC, SSG, Intel
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to