From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: insyde.com, ip: 210.71.195.42, mailfrom: tim.lewis@insyde.com) Received: from out02.hibox.biz (out02.hibox.biz [210.71.195.42]) by groups.io with SMTP; Thu, 05 Sep 2019 10:25:11 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AmAAARQXFd/ws0GKxlHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgRWBb4EvhCGIHIh/jn2EE4YKgXsJAQEBAQEBAQEBCCMMAQG?= =?us-ascii?q?EPwKCWTQJDgIMAQEFAQEBAQEGBIVYQwyFSgEBAgMIAhkKITgFBwINBAQBAQ4?= =?us-ascii?q?aAwIbGBUJCAIEARILBQ0EgwKBHXyOU5tvgTIaAoQaAYEUhQWBNAGBYoN/iC2?= =?us-ascii?q?EIz6EUCqCVYJYBIxQiCeBIZYYB4kZjXEbgyOKWQOKd4xPgSuHfZEIgVKCEHB?= =?us-ascii?q?QgmwJNohZiA9Tj1ABAQ?= X-IronPort-AV: E=Sophos;i="5.64,470,1559491200"; d="scan'208,217";a="16867912" Received: from unknown (HELO hb3-BKT201.hibox.biz) ([172.24.52.11]) by out02.hibox.biz with ESMTP; 06 Sep 2019 01:25:09 +0800 Received: from unknown (HELO hb3-BKT103.hibox.biz) ([172.24.51.13]) by hb3-BKT201.hibox.biz with ESMTP; 06 Sep 2019 01:25:08 +0800 Received: from unknown (HELO hb3-IN01.hibox.biz) ([172.24.12.11]) by hb3-BKT103.hibox.biz with ESMTP; 06 Sep 2019 01:25:08 +0800 X-Remote-IP: 172.24.153.226 X-Remote-Host: No hostname X-SBRS: None X-MID: 27140919 X-Auth-ID: tim.lewis@insyde.com X-EnvelopeFrom: tim.lewis@insyde.com hiBox-Sender: 1 Received: from unknown (HELO DESKTOPHG9V3E8) ([172.24.153.226]) by hb3-IN01.hibox.biz with ESMTP/TLS/AES256-SHA; 06 Sep 2019 01:25:07 +0800 From: "Tim Lewis" To: , In-Reply-To: Subject: Re: [edk2-devel] Mappings and StdLib Date: Thu, 5 Sep 2019 10:25:05 -0700 Message-ID: <03be01d5640e$dd929ab0$98b7d010$@insyde.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKas1prrejHzdPsaRkFF2PKradNuaWStlqg Content-Type: multipart/alternative; boundary="----=_NextPart_000_03BF_01D563D4.31354950" Content-Language: en-us ------=_NextPart_000_03BF_01D563D4.31354950 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andrew =E2=80=93 =20 There is a standard call that provides this service, but I am porting over= BSD utils to the shell and they just take a straight path and call open. S= o I want open to behave the way I expect it to. IN fact, the low level code= separates out the =E2=80=9Cdrive=E2=80=9D from the path already, but the = current library doesn=E2=80=99t add in the mappings into the list that gets= created (it is used for stdin: stdout: and stderr:) The thing is that the = underlying Shell APIs do handle this case, but the mapping is stripped befo= re it gets to that layer. =20 Tim =20 From: devel@edk2.groups.io On Behalf Of Andrew Fish= via Groups.Io Sent: Wednesday, September 4, 2019 5:35 PM To: devel@edk2.groups.io; tim.lewis@insyde.com Subject: Re: [edk2-devel] Mappings and StdLib =20 Tim, =20 I don't know about the plans with the StdLib, but I do remember a long tim= e ago with the old shell there was a protocol that let you translate volume= names (mappings) into handles and device paths.=20 =20 So you could write a simple library that has 2 styles of APIs: 1) Handle + FilePath in Shell mapping with Volume Name out 2) Shell file path with mapping Volume names in and Simple File System han= dle Out with the file path a) A device path out version of this is also useful =20 You can make the lib just error return if the Shell protocol does not exis= t so you don't make it a requirement. The caller handles that failure as th= e current working volume/directory case.=20 =20 Thanks, =20 Andrew Fish On Sep 4, 2019, at 5:14 PM, Tim Lewis > wrote: =20 Following up on my last e-mail, I guess I had the wrong assumption: there = doesn=E2=80=99t appear to be a way to resolve mappings within StdLib. =20 Are there any plans here? =20 Thanks, =20 Tim =20 ------=_NextPart_000_03BF_01D563D4.31354950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andrew =E2=80= =93

 

There is a standard call that provides this service, but I am portin= g over BSD utils to the shell and they just take a straight path and call o= pen. So I want open to behave the way I expect it to. IN fact, the low leve= l code separates out the =E2=80=9Cdrive=E2=80=9D=C2=A0 from the path alread= y, but the current library doesn=E2=80=99t add in the mappings into the lis= t that gets created (it is used for stdin: stdout: and stderr:) The thing i= s that the underlying Shell APIs do handle this case, but the mapping is st= ripped before it gets to that layer.

 

Tim

 

From: dev= el@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Andrew F= ish via Groups.Io
Sent: Wednesday, September 4, 2019 5:35 PM
<= b>To: devel@edk2.groups.io; tim.lewis@insyde.com
Subject: Re:= [edk2-devel] Mappings and StdLib

 

Tim,

 

I do= n't know about the plans with the StdLib, but I do remember a long time ago= with the old shell there was a protocol that let you translate volume name= s (mappings) into handles and device paths. 

=

 

S= o you could write a simple library that has 2 styles of APIs:

1) Handle + FilePath in Shell mapping with= Volume Name out

2) Shell fil= e path with mapping Volume names in and Simple File System handle Out with = the file path

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 a) A device path out version of this is al= so useful

 

You can make the lib just error return if= the Shell protocol does not exist so you don't make it a requirement. The = caller handles that failure as the current working volume/directory case.&n= bsp;

 

Thanks,

 

Andrew Fish



On S= ep 4, 2019, at 5:14 PM, Tim Lewis <tim.lewis@insyde.com> wrote:

 

Following up on my= last e-mail, I guess I had the wrong assumption: there doesn=E2=80=99t app= ear to be a way to resolve mappings within StdLib.

 

= Are there any plans here?

&nb= sp;

Thanks,

 

Tim

 

------=_NextPart_000_03BF_01D563D4.31354950--