From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 From: Kyohei Kadota Date: Fri, 3 Aug 2018 23:35:21 +0900 Message-ID: To: 9fans@9fans.net Content-Type: multipart/alternative; boundary="0000000000001325ea057288d7ae" Subject: [9fans] question about #include_next directive Topicbox-Message-UUID: d9b5ae58-ead9-11e9-9d60-3106f5b1d025 --0000000000001325ea057288d7ae Content-Type: text/plain; charset="UTF-8" Hi, fans. I'm trying to port LibreSSL on native Plan 9. Some functions are works now: 1. git clone https://github.com/lufia/portable && cd portable 2. rc ./update.rc 3. ape/patch -p0 #endif ! #line 1 "/usr/lufia/" cpp: :2 Unknown preprocessor control include_next I had no choice but to rewrite #include_next like: compat.h: #ifdef Plan9 #define SYS_PATH(x) /sys/include/ape/x #else #define SYS_PATH(x) sys_##x #endif #define SYSINCLUDE(x) string.h: #include SYSINCLUDE(string.h) sys_string.h: #include_next This works but I think this way is not good because developer should manage two files. Is there any good way? --0000000000001325ea057288d7ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, fans.

I'm trying to = port LibreSSL on native Plan 9.
Some functions are works now:

=C2=A0 =C2=A0 1. git clone https://github.com/lufia/portable && cd por= table
=C2=A0 =C2=A0 2. rc ./update.rc
=C2=A0 =C2=A0 3. = ape/patch -p0 <plan9/crypto.patch
=C2=A0 =C2=A0 4. ape/patch -= p0 <plan9/ssl.patch
=C2=A0 =C2=A0 5. ape/patch -p0 <plan9/a= pps.patch
=C2=A0 =C2=A0 6. for(i in crypto ssl apps/openssl) @{ c= d $i; mk }

I have difficulty in porting header fil= es.
Some headers of LibreSSL has #include_next GCC extended direc= tive, but Plan 9's cpp can't process #include_next directive.
=
When cpp processes a header containing #include_next, it exits with &q= uot;Unknown preprocessor control #include_next" error even if ignoring= by #if and #endif.

=C2=A0 =C2=A0 % cat <<! = | cpp
=C2=A0 =C2=A0 #if 0
=C2=A0 =C2=A0 #include_next &= lt;u.h>
=C2=A0 =C2=A0 #endif
=C2=A0 =C2=A0 !
=C2=A0 =C2=A0 #line 1 "/usr/lufia/<stdin>"
=C2=A0 =C2=A0 cpp: <stdin>:2 Unknown preprocessor control include_n= ext

I had no choice but to rewrite #include_= next like:

compat.h:
=C2=A0 =C2=A0 #ifde= f Plan9
=C2=A0 =C2=A0 #define SYS_PATH(x) /sys/include/ape/x
=C2=A0 =C2=A0 #else
=C2=A0 =C2=A0 #define SYS_PATH(x) sys_#= #x
=C2=A0 =C2=A0 #endif
=C2=A0 =C2=A0 #define SYSINCLUD= E(x) <SYS_PATH(x)>

string.h:
=C2= =A0 =C2=A0 #include SYSINCLUDE(string.h)

sys_strin= g.h:
=C2=A0 =C2=A0 #include_next <string.h>

<= /div>
This works but I think this way is not good because developer sho= uld manage two files.
Is there any good way?
--0000000000001325ea057288d7ae-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6A9EF44411819E268CC3A6175C6F2C10@felloff.net> Date: Fri, 3 Aug 2018 17:19:36 +0200 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: CAFMepc=tjm3V4VPYzsAWTaHGRcSi3b0C5Z44W8J9oFbhrX5apw@mail.gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] question about #include_next directive Topicbox-Message-UUID: d9ca9da4-ead9-11e9-9d60-3106f5b1d025 what are you intending to use libressl for in native plan9? plan9 already has a crypto library (libsec) which is a fraction of the size of openssl and works quite well. i'v been using it to implement many crypto protocols to talk to the outside world. for tls, plan9 uses devtls which allows you to wrap any file descriptor to make it a encrypted channel and then you get a filedescriptor back that you can pass arround, so the programs communicating actually dont even need to know the secret session keys. so adding tls support to programs is very trivial in plan9. one function call basically to wrap the fd. while in unix programs that want encryption have to change all ther read and wirte calls to use special libssl functions. also, plan9 has factotum to hold and work on secret keys. you can use factotum todo the public key operations like signing, encryption and decryption using the key for you so keys never have to leave factotum. even if you port programs from unix, it might be worth taking a step back and learn how plan9 does crypto, which is quite advanced compared to traditional unix. -- cinap From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <6A9EF44411819E268CC3A6175C6F2C10@felloff.net> In-Reply-To: <6A9EF44411819E268CC3A6175C6F2C10@felloff.net> From: Kyohei Kadota Date: Sat, 4 Aug 2018 03:35:38 +0900 Message-ID: To: 9fans@9fans.net Content-Type: multipart/alternative; boundary="0000000000005eee4305728c321c" Subject: Re: [9fans] question about #include_next directive Topicbox-Message-UUID: d9d5c364-ead9-11e9-9d60-3106f5b1d025 --0000000000005eee4305728c321c Content-Type: text/plain; charset="UTF-8" Thanks cinap. I know Plan 9's devtls is more useful than Unix's libraries, but finally want to use git and github.com on Plan 9. My team works frequently with git. Git-wrapper can clone but it can't merge, push, and so on. And I started to port LibreSSL because official git links some libraries such as libexpat, libcurl, and openssl. 2018-08-04 0:22 : > what are you intending to use libressl for in native plan9? > plan9 already has a crypto library (libsec) which is a fraction of the > size of openssl and works quite well. i'v been using it to implement > many crypto protocols to talk to the outside world. > > for tls, plan9 uses devtls which allows you to wrap any file descriptor > to make it a encrypted channel and then you get a filedescriptor back > that you can pass arround, so the programs communicating actually dont > even need to know the secret session keys. so adding tls support to > programs is very trivial in plan9. one function call basically to wrap > the fd. while in unix programs that want encryption have to change all > ther read and wirte calls to use special libssl functions. > > also, plan9 has factotum to hold and work on secret keys. you can use > factotum todo the public key operations like signing, encryption and > decryption using the key for you so keys never have to leave factotum. > > even if you port programs from unix, it might be worth taking a step > back and learn how plan9 does crypto, which is quite advanced compared > to traditional unix. > > -- > cinap > > --0000000000005eee4305728c321c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks cinap.

I know Pl= an 9's devtls is more useful than Unix's libraries, but finally wan= t to use git and github.com on Plan 9.
My team works frequently with git.

Git-wra= pper can clone but it can't merge, push, and so on.
And I sta= rted to port LibreSSL because official git links some libraries such as lib= expat, libcurl, and openssl.

2018-08-04 0:22 <cinap_lenrek@felloff.net>:
what are you = intending to use libressl for in native plan9?
plan9 already has a crypto library (libsec) which is a fraction of the
size of openssl and works quite well. i'v been using it to implement many crypto protocols to talk to the outside world.

for tls, plan9 uses devtls which allows you to wrap any file descriptor
to make it a encrypted channel and then you get a filedescriptor back
that you can pass arround, so the programs communicating actually dont
even need to know the secret session keys. so adding tls support to
programs is very trivial in plan9. one function call basically to wrap
the fd. while in unix programs that want encryption have to change all
ther read and wirte calls to use special libssl functions.

also, plan9 has factotum to hold and work on secret keys. you can use
factotum todo the public key operations like signing, encryption and
decryption using the key for you so keys never have to leave factotum.

even if you port programs from unix, it might be worth taking a step
back and learn how plan9 does crypto, which is quite advanced compared
to traditional unix.

--
cinap

--0000000000005eee4305728c321c-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lyndon Nerenberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 3 Aug 2018 11:54:11 -0700 References: <6A9EF44411819E268CC3A6175C6F2C10@felloff.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: Message-Id: Subject: Re: [9fans] question about #include_next directive Topicbox-Message-UUID: d9dba568-ead9-11e9-9d60-3106f5b1d025 > On Aug 3, 2018, at 11:35 AM, Kyohei Kadota wrote: >=20 > I know Plan 9's devtls is more useful than Unix's libraries, but = finally want to use git and github.com on Plan 9. > My team works frequently with git. It might be easier to just teach git to use the native Plan9 TLS API.= From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <6A9EF44411819E268CC3A6175C6F2C10@felloff.net> From: Dave MacFarlane Date: Fri, 3 Aug 2018 15:10:23 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] question about #include_next directive Topicbox-Message-UUID: d9e026a6-ead9-11e9-9d60-3106f5b1d025 How advanced is your git usage? If you're only doing simple merges and pushes dgit (https://github.com/driusan/dgit) is approaching useful since someone taught me how to throw the official git test suite at it. I definitely wouldn't recommend it as a daily driver, but if you only want to push a couple things here and there, don't rebase, and have a fairly linear history it might work for you. - Dave On Fri, Aug 3, 2018 at 2:35 PM, Kyohei Kadota wrote: > Thanks cinap. > > I know Plan 9's devtls is more useful than Unix's libraries, but finally > want to use git and github.com on Plan 9. > My team works frequently with git. > > Git-wrapper can clone but it can't merge, push, and so on. > And I started to port LibreSSL because official git links some libraries > such as libexpat, libcurl, and openssl. > > 2018-08-04 0:22 : >> >> what are you intending to use libressl for in native plan9? >> plan9 already has a crypto library (libsec) which is a fraction of the >> size of openssl and works quite well. i'v been using it to implement >> many crypto protocols to talk to the outside world. >> >> for tls, plan9 uses devtls which allows you to wrap any file descriptor >> to make it a encrypted channel and then you get a filedescriptor back >> that you can pass arround, so the programs communicating actually dont >> even need to know the secret session keys. so adding tls support to >> programs is very trivial in plan9. one function call basically to wrap >> the fd. while in unix programs that want encryption have to change all >> ther read and wirte calls to use special libssl functions. >> >> also, plan9 has factotum to hold and work on secret keys. you can use >> factotum todo the public key operations like signing, encryption and >> decryption using the key for you so keys never have to leave factotum. >> >> even if you port programs from unix, it might be worth taking a step >> back and learn how plan9 does crypto, which is quite advanced compared >> to traditional unix. >> >> -- >> cinap >> > -- - Dave From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <6A9EF44411819E268CC3A6175C6F2C10@felloff.net> From: hiro <23hiro@gmail.com> Date: Sat, 4 Aug 2018 00:55:30 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] question about #include_next directive Topicbox-Message-UUID: d9e5aae0-ead9-11e9-9d60-3106f5b1d025 don't mix work and play. this will end badly.