James Carlson wrote:
Darren Reed writes:
To meet these requirements, this proposal suggests two new
functions: ddi_minor_alloc and ddi_minor_free.

What's wrong with the existing id_alloc() function?

Well for one, not many people know about it/them because there
is/are no man page/s...

But seriously, I'd rather see a layered interface that used
the correct types (major_t, minor_t) than encourrage these to
be used and the need for "newminor = (minor_t)id_alloc(...)".

I need to look at id_alloc() more closely, but if it is using
vmem_*() directly then it may not be space efficient if the
number space becomes fragmented.

Each of the following entry points into the driver will be
supplied with a new, extra, paramter: aread, awrite, chpoll,
dump, ioctl, mmap, print, read, segmap, strategy and write.
close is supplied pointer to the context pointer, which the

And for this part, why are the ddi_soft_state(9F) functions not
sufficient?

A new, cloned and opened device, doesn't necessarily mean there
is a new instance of a device. For example, you might have n
instances of a device present, each one using ddi_soft_state(9F),
that presents a unique device node that can be used with a cloning
open. ddi_soft_state(9F) is there for instance attachment management
and I'd rather not confuse its purpose with supporting cloned opens.

Darren

_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to