Artem Kachitchkine wrote:
>
>> I'm *really* not a fan of inconsistent property handling -- magic
>> encoded strings like what is proposed here for portflag seems,... ugly.
>
> I've heard of magic numbers, but this is the first time I'm hearing of
> magic strings. What's wrong with descriptive names? Would it help if
> they were in lower case or camel case?
>
>> Is there a reason why driver/instance number are inadequate to
>> properly identify a usb device in driver.conf? (usb(4) sheds no
>> light on how usb properties work.)
>
> Moving device to another USB port can change instance number. Pointing
> your finger and assigning a property to "this" device needs a better
> definition of "this", some sort of UUID, and serial number is the
> closest thing USB has to offer.
I misread serial number thinking it was a "serial device port number" or
somesuch magic value from the USB enumeration. Not an actual mfgr's
serial number. Given that you're using the latter and not the former,
I'm much happier.
>
> > Didn't we just see a different case for usb configuration using .conf
> > properties?
>
> That case simply promoted stability of existing properties. It has
> been noted in the discussion that instance-based properties have
> limitations. This case makes it possible to add a new mode for
> "ignore-cd" in the future.
Hmmm.... the concern I have here is inconsistency between the two schemes.
>
>> "portflag" as specified looks like a call generator, and a "hack".
>
> "portflag" as specified looks very similar to sd.conf sd-config-list -
> PSARC/2008/465, eagerly approved by this committee.
OK, I was not familiar with that case.
>
>> It does seem that perhaps an SMF property or something like what
>> Brussels does for NIC drivers is called for here.
>
> driver.conf is not perfect, but improving on it is not this case.
Maybe not in the general case, but I think it is fair to recommend that
the project team consider alternative, perhaps superior, methods to
configure such tunables. driver.conf has so many problems that IMO it
ought be strongly discouraged for normal kinds of tunables. (For
tunables that will rarely, or never, be used, such as interrupt
frequencies of audio devices, I'm OK with it. But for "typically" used
values that may be required in order to allow the device to operate
*correctly*, I'd really prefer to see a better solution.)
I feel strongly enough about this to recommend it and withhold a +1, but
not strongly enough to derail the case over it.
-- Garrett
>
> -Artem
