Chris Horne writes:
> With a Solaris goal of 'supporting the developer', I believe that
> enabling a driver to be cp-clonable makes the development of subsequent
> bug fixes and enhancements easier - especially for drivers involved in
> mounting the root device (where you don't want early use of development
> bits to cause the machine to fail to boot).
That's the only one of these scenarios that makes sense to me.
OK ... as I said before, I was mostly curious what the motivation was,
as I've worked on all sorts of drivers, and it's hard for me to see
how or why I'd ever really want to clone one by copying the binary. :-/
> software he also ends up deleting the alias for the media changer. The
> proper way of doing this would be to add and remove aliases via
> "update_drv -a/-d -i", but there is existing practice and third party
> products that say "run 'rem_drv sgen'". Making a driver cp-clonable
> could provide a workaround that accommodates existing practice
yikes.
I hope that's never used as anything other than as a work-around. I
can see this getting confusing over time. Especially if 'cp' is
really what's used -- after patching the system, those cp-based clones
will be using old slightly-different code, but the originals will be
using new code. The conflicts could be spectacular.
There are instances of drivers using name-based information to ensure
that there's only one instance of a control node or user-space daemon
or the like.
Could the feature perhaps need a warning label? ("For driver
developers only; administrators, please don't try this at home.")
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
