James Carlson wrote:
> Christopher Horne writes:
>
>> For maximum flexibility, it is best if a driver does not have
>> compiled-in knowledge of its own name. Existing
>>
>
> What does "maximum flexibility" mean here? Under what normal
> conditions would a driver need to be installed under different names
> ... ?
>
> I guess I have nothing against the interface -- it seems obvious
> enough in design -- but the usage seems pretty obscure.
>
The only thing I can think of is in some weird situation, where, for
example, a driver or module is having something done on behalf of it in
some framework somewhere.
For example, something like xxx_framework_initops(struct modlinkage *).
It does seem of pretty limited utility, though.
>
>> information. The ddi_modname() interface was added in s10_59
>> as part of CR5033382 "sd driver should not depend on hard-coded
>> driver name".
>>
>
> That shows a debug example, where (I'd guess) someone could just as
> easily recompile with a new name. Are there other cases where
> renaming on the fly makes sense?
>
>
>> + char *mod_modname(struct modlinkage *modlinkage);
>>
>
> Code review nit: I suggest 'const char *' as a return value here (and
> perhaps a const argument as well). The string this returns shouldn't
> normally be modified by a user. (And if it is ...)
>
YES PLEASE! Its really quite annoying when folks don't use const char *
when they should. Its more important, IMO, that the functions take
const pointers than return them. (The fact that large portions of our
DDI are not const-ipated, makes it really hard to use const char *
elsewhere where we should. Fixing this across the board may actually
gain some performance improvements due to better optimization.)
-- Garrett
