On 05/26/10 10:36, Shawn Walker wrote:
On 05/25/10 09:32 PM, Felix Feng wrote:
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.
Isn't a man page a more appropriate place to document the available
properties? Especially since I imagine many users will want a list of
what the valid values are for the property or an explanation of its
purposes.
Man page will be updated to document all available properties for
keyboard configurations. And I think it's better to list these
properties in system/keymap too. In this way users and installer only
need to change property values.
------
Regards,
Felix
Cheers,
-Shawn
_______________________________________________
opensolaris-arc mailing list
[email protected]
