James Carlson wrote:
> 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.
>
You're making an assumption that these two sets are distinct. I'm not
sure they are. I think the latter can lead to the former.
Put another way, I'm afraid some FOSS developers will find out where we
squirreled it away, and hard code it into configure scripts, or even
into binaries. (Much of the FOSS software we wind up dealing with comes
from places where developers have never even heard of ABI compatibility,
much less care about it.)
So having a name readily available (too easily, in other words) may keep
the good citizens (the Oracles of the world) good, but it won't shield
them from the actions of the citizens who don't know about or don't care
about our stability rules.
> 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.
>
>
True, but when we can avoid exposing details in a way that might be
confused with "supported", we should. Its sort of like putting out
headers with driver private ioctls. Sure, its been done, and often
harmless. But for the trivial cost of effort it would take to keep
those from shipping in the binary product, I think the problem-avoidance
justify the cost.
>> 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.
>
I will point out that while this is simpler in the short run, in the
long run it may create other difficulties that make the cost comparison
not so obvious. For example, bfu and upgrade will need to be modified
to rename the node on upgrade. If the node is kept in the kernel, then
there are no upgrade implications. (And ultimately, each of those
approaches I mentioned could probably be implemented in less than 50
lines of code.)
-- Garrett
