Thanks Andy.
I used your example as a base for the implementation.
All is done now and checked in in the trunk.
Anton Pak
On Tue, 13 Jul 2010 18:27:23 +0400, Andy Cress <[email protected]>
wrote:
> Here is the logic that I use to display the GUID/UUID, where devrec
> contains the 16 byte binary UUID:
> for (i=0; i<16; i++) {
> if ((i == 4) || (i == 6) || (i == 8) || (i == 10)) s = "-";
> else s = "";
> printf("%s%02x",s,devrec[i]);
> }
> It would be a pretty simple subroutine.
>
> Andy
>
> -----Original Message-----
> From: Anton Pak [mailto:[email protected]]
> Sent: Tuesday, July 13, 2010 6:17 AM
> 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
