Garrett D'Amore writes:
> Publishing it under a different name might be a workaround, but as
> others have pointed out, you'll find people who write scripts to locate
> it, and then the funky "semi-private" name "evolves" into a new de-facto
> standard for Solaris. Urk. Better not to expose the name at all.
Those same squirrelly people could presumably find it via /devices
just as readily as finding it buried under a strange name in /dev.
I don't buy that argument, because I see two separate issues here:
- People who stumble into using it through no fault of their own,
and end up hurt by incompatible changes we may make before
stabilizing.
- People who deliberately go out of their way to find the
undocumented stuff we've got.
I hope that we'll protect the former. I have little sympathy for the
latter. If that happens, I hope we'll break them, because that's just
beyond the pale. We can't protect against people who are hacking.
> The internal pathname approach is, IMO, far better. But it may have the
> same limitations that /dev nodes have, which is that they are physical
> paths rather than logical paths. A possible workaround is to use a
> pseudo-driver to provide the "logical" path. Another possible
> workaround is to just have the kernel components crawl the device tree
> looking for the physical path. Yet another is to create a "registry"
> where physical drivers can register their physical path so that the
> kernel consumers can find them. Which one of these is best will vary.
A much simpler mechanism is to use the existing device linkage tools
to create a /dev node, and just provide it an "unexpected" name for
now. You'd then rename into the right location when it's made public.
If you want to use /dev/freeman temporarily, that'd be fine.
--
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
