On 05/26/10 00:11, Antonello Cruz wrote:
On 05/24/10 10:48 PM, Felix Feng wrote:
On 05/24/10 19:16, Felix Feng wrote:
On 05/25/10 01:24, Antonello Cruz wrote:
On 05/22/10 09:35 AM, Felix Feng wrote:
于 2010-5-22 00:19, Garrett D'Amore 写�:
Does it make sense to use some special value (zero or -1) to mean
uninitialized? That way could at least preserve the type.
But the special value is invalid for keyboard configurations. If
it is
set in keyboard properties, users may get confused. So I prefer
'null'
to mean uninitialized. Thanks.
This is a valid point. However, if I understood correctly, these are
values set in the SMF manifest. You can have comments in the manifest
explaining the uninitialized value. Moreover, you can leverage SMF
templates to validate the values, but if you use astring, you cannot
validate ranges.
I don't understand why a missing value in the SMF repository can not
be inferred as uninitialized. Could you please elaborate that?
Hi Antonello,
In fact, in this case I've already used missing value(null,
value='') to
mean uninitialized. You can see reference [2] in the PSARC material
for
details. For the data type, it seems a missing value is invalid for
'count' type. And for 'integer' type, a missing value is treated as 0.
So I use astring to store the values. When users configure keyboard
using system/keymap service, kbd will be called to validate the
values(ranges) and set the values into kernel. Thanks.
The problem here is that you are assuming empty value as missing
value, and I was using missing value when I wanted to say missing
property. What happens to your code if the property is not in the SMF
repository? You should get a SCF_ERROR_NOT_FOUND and I am suggesting
that you use that as uninitialized.
Hi Antonello,
Thanks for your instructions. Yes, the missing property can be used as
uninitialized. But in this case if I use missing property, users need to
add these properties manually when they want to configure their keyboard
through system/keymap service, right? And OpenSolaris Installer needs to
populate keyboard configuration to system/keymap property. kbd(1) is
also a consumer of the property. One of the purpose of this project is
to export these properties as the interfaces so that those consumers and
users can easily use them.
Won't the users and installers have to change the null/empty value
with the value they want to configure the keyboard? How is that any
different than changing the value?
Yes, users only need to change the empty value to configure the keyboard
in empty value case. But if missing property is used, users need to add
a property including property name, property type and property value.
Users may not know the exact configuration name. And in empty value
case, kbd will be called to validate the value which users change. But
in missing property case, when users input a wrong property name, it's
not easy to validate it. Moreover, in empty case, if users want to know
which keyboard configurations they can change in system/keymap, they can
easily get the configuration list using svccfg or svcprop command. But
if missing property is used, system/keymap can not provide users such
list to instruct users to configure the keyboard.
I don't follow your concern about the properties being interfaces and
the necessity for an explicit uninitialized value in the SMF
repository/manifest.
The properties come from the legacy keyboard configuration file -
/etc/default/kbd. /etc/default/kbd will be removed and the interfaces in
the file need to be preserved in system/keymap service. And explicit
properties in system/keymap service are more obvious and easier for
users to use. So I think explicit properties in system/kemap are
necessary, although uninitialized values are assigned to them.
------
Regards,
Felix
Antonello
------
Regards,
Felix
Antonello
------
Regards,
Felix
Antonello
_______________________________________________
opensolaris-arc mailing list
[email protected]
