Uli,

I am looking forward to see your application in action. :)

        Anton Pak


On Fri, 16 Jul 2010 11:52:08 +0400, Kleber, Ulrich (NSN - DE/Munich)  
<[email protected]> wrote:

> Hi Anton,
> I moved to Andy's proposal now.
> Sometimes I use stuff from the utils, but for printing the domain
> info, I used the same format as hpi_shell does. So I copied some
> code from there.
>
> hpi_shell and the clients often work very differently.
> Maybe that's good, so we provide two different examples for HPI usage.
>
> I hope to come to something useful with this hpidomain client. But I
> need to do some more work for domain discovery stuff, before it makes
> sense
> to send it out.
>
> Cheers,
> Uli
>
>> -----Original Message-----
>> From: ext Anton Pak [mailto:[email protected]]
>> Sent: Tuesday, July 13, 2010 12:17 PM
>> To: [email protected]
>> Subject: Re: [Openhpi-devel] Proposal: remove libopenhpiutils
>> dependency onlibuuid
>>
>> Uli,
>>
>> I see nothing wrong in using uuid_unparse for client application.
>> Unless you have no concerns about using it under different platforms.
>>
>> On other side hpi_shell uses its internal decode_guid from service.c.
>>
>> If you look into sahpi_struct_utils.c, you will see:
>>
>> #if defined(__sun) && defined(__SVR4)
>>      uuid_unparse((unsigned char *)ResourceInfo->Guid, tempstr);
>> #else
>>      uuid_unparse(ResourceInfo->Guid, tempstr);
>> #endif
>>
>> Did you use uuid_unparse in the same way in your client app?
>> If no, there will be problems on Solaris.
>>
>> By the way, did you try to use functions from libopenhpiutils
>> for printing
>> different HPI data structures for your client app?
>>
>>      Anton Pak
>>
>> On Tue, 13 Jul 2010 14:00:53 +0400, Kleber, Ulrich (NSN - DE/Munich)
>> <[email protected]> wrote:
>>
>> > Hi,
>> > I created a new client hpidomain that is able to walk the DRT and
>> > display
>> > all domain info. I used uuid_unparse there, too.
>> > But if we create an own util to display GUID, I'm fine.
>> > At the moment we don't provide much for GUID, but that could change.
>> >
>> > At the moment there is not much to walk on in the DRT, so I
>> can't really
>> > test
>> > that client, so I stayed quiet ;-).
>> > Cheers,
>> > Uli
>> >
>> >> -----Original Message-----
>> >> From: ext Anton Pak [mailto:[email protected]]
>> >> Sent: Tuesday, July 13, 2010 11:52 AM
>> >> To: OpenHPI-devel
>> >> Subject: [Openhpi-devel] Proposal: remove libopenhpiutils
>> >> dependency onlibuuid
>> >>
>> >> Hello!
>> >>
>> >> I have the following proposal:
>> >>
>> >> Currently libopenhpiutils depends on libuuid.
>> >> Working on OpenHPI base library for Windows
>> >> I have problems with libuuid there.
>> >>
>> >> Investigation shows that libopenhpiutils uses only
>> >> uuid_unparse function from this library.
>> >> See file utils/sahpi_struct_utils.c, function
>> oh_build_resourceinfo.
>> >>
>> >> Also the usage of this function differs on Solaris and Linux
>> >> and we have #ifdefs there.
>> >>
>> >> The function uuid_unparse just prints
>> SaHpiRptEntryT.ResourceInfo.Guid
>> >> (which is unsigned char[16]) as a 36-byte string (plus
>> tailing '\0')
>> >> of the form like 1b4e28ba-2fa1-11d2-883f-b9a76.
>> >>
>> >> I guess it can be done internally with simple printf call or
>> >> small static
>> >> function.
>> >> After that there is no need for libuuid dependancy for
>> libopenhpiutils
>> >>
>> >> What say?
>> >>
>> >> Just created feature request #3028899 for this.
>> >>
>> >>   Anton Pak
>> >>
>> >> --------------------------------------------------------------
>> >> ----------------
>> >> This SF.net email is sponsored by Sprint
>> >> What will you do first with EVO, the first 4G phone?
>> >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> >> _______________________________________________
>> >> Openhpi-devel mailing list
>> >> [email protected]
>> >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >>
>> >
>> >
>> --------------------------------------------------------------
>> ----------------
>> > This SF.net email is sponsored by Sprint
>> > What will you do first with EVO, the first 4G phone?
>> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> > _______________________________________________
>> > Openhpi-devel mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>>
>>
>> --------------------------------------------------------------
>> ----------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Openhpi-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel

Reply via email to