Re: Rules for Instance WAS PIC testing WAS OSD ALERT

[Frank Mc Alinden]

Hi Tony

>A non configured device can boot with an instance of 'default'
>initially,
>but _must_ be capable of remembering it's newly configured instance
>(i.e.
>must not loose it at reboot).

What im trying to say is ...a new OSD device when its first connected would
be
aec-tvosd.default and it would then send a config heartbeat and get a new
instance...I thought the default instance alerted xpl hal that this is a
new
device???...

Probably got this all wrong again.....sorry

Frank


----- Original Message -----
From: Tony Tofts
To: <a
href="/group/ukha_xpl/post?postID=Rc6X8dSHEyM4eRQTm36kymAdfugpYSsqNbKg9Gj9Ho7kAumUhtBRlBAV3zkUzWqLe6ofjE2DO7chzjY7Bzk6p1yE">ukha_xpl@xxxxxxx</a>
Sent: Wednesday, December 10, 2003 8:05 PM
Subject: [ukha_xpl] Rules for Instance WAS PIC testing WAS OSD ALERT


> and i assume a non configured device would have default....?

A non configured device can boot with an instance of 'default' initially,
but _must_ be capable of remembering it's newly configured instance (i.e.
must not loose it at reboot).

The xpl manager will _not_ allow a device to be configured with an instance
of 'default' as this is a reserved (the only one) instance name to aid
identification of a devices ability to remember it's instance.

The following might be a bit long winded, but explains it in more detail

There are basically 4 types of device/app (referred to as device only
hereon)

A) cannot remember an instance on reboot, cannot generate unique instance
B) cannot remember an instance on reboot, can generate unique instance
C) can remember an instance on reboot, cannot generate unique instance
D) can remember an instance on reboot, can generate a unique instance
(might
be supplied on command line prompt or similar)

Type 'a' is for the simplest of devices, as it cannot create a unique
instance, nor remember an assigned instance there can only be _one_ of
these
devices on a given xpl network (must never be 'default')

Type 'b' is for devices that can generate their own uniqe instance, but
cannot remember a change to the instance after a reboot. i.e. if it's
ethernet it might use it's ip address for it's instance (must never be
'default')

Type 'c' is for devices that don't generate a unique instance on startup,
but _can_ remember an assigned instance. It should always start with an
instance of 'default'

Type 'd' is for devices that can generate a unique instance and remember
it.
This applies to most current applications and various devices (e.g.
rioplayxpl)

All devices are assumed to be able to store a change to their instance once
running, even type 'a'. xPLHal config process tracks changes to the
instance, and if necessary, will reconfig the device multiple times to
restore it to the state it was in before being switched off, but this
always
must start from a unique instance (which is why a device cannot be
configured with an instance of 'default' as this is used by multiple
devices
for initial configuration).

So to sum up, where a device remembers it's last assigned instance, it will
receive a single config for xplhal to return it to it's required state.
Where it starts with a base unique instance it is configured thru all
cycles
to return it to it's last state.

All these devices would always start with a config.app or config.basic

Where a device wishes to remember it's own settings (e.g. pc registry or
non-volatile storage) it is free to start with a hbeat.app ot hbeat.basic,
and will not be configured unless manually sent a config from xpl manager.

Hope this clarifies things.

As a side note, when xplhal configures a device it then requests it's
current config. That way if any configured item was invalid or failed,
xplhal will always know the true config state of the device.

Regards
Tony