[9fans] question about #include_next directive

[9fans] question about #include_next directive

[Kyohei Kadota]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

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 <plan9/crypto.patch
    4. ape/patch -p0 <plan9/ssl.patch
    5. ape/patch -p0 <plan9/apps.patch
    6. for(i in crypto ssl apps/openssl) @{ cd $i; mk }

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

    % cat <<! | cpp
    #if 0
    #include_next <u.h>
    #endif
    !
    #line 1 "/usr/lufia/<stdin>"
    cpp: <stdin>: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) <SYS_PATH(x)>

string.h:
    #include SYSINCLUDE(string.h)

sys_string.h:
    #include_next <string.h>

This works but I think this way is not good because developer should manage
two files.
Is there any good way?

[-- Attachment #2: Type: text/html, Size: 1919 bytes --]

Re: [9fans] question about #include_next directive

[hiro]

don't mix work and play. this will end badly.

Re: [9fans] question about #include_next directive

[Dave MacFarlane]

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 <lufia@lufia.org> 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 <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
>>
>



--
- Dave

Re: [9fans] question about #include_next directive

[Lyndon Nerenberg]

> On Aug 3, 2018, at 11:35 AM, Kyohei Kadota <lufia@lufia.org> wrote:
> 
> 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.

Re: [9fans] question about #include_next directive

[Kyohei Kadota]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

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 <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
>
>

[-- Attachment #2: Type: text/html, Size: 2068 bytes --]

Re: [9fans] question about #include_next directive

[cinap_lenrek]

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