From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM2 development <lvm-devel@redhat.com>
Cc: buildroot@uclibc.org,
LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] [lvm-devel] MUSL fun
Date: Sat, 13 Feb 2016 22:36:20 +0100 [thread overview]
Message-ID: <56BFA1D4.20105@redhat.com> (raw)
In-Reply-To: <CA+BsyQ5Lhvys2eea64T_qE49DaE7gH6QEPsAFi+Nn7VfJ_Ourw@mail.gmail.com>
Dne 13.2.2016 v 22:31 Brendan Heading napsal(a):
>>> There is a reason from lvm2 implementation here - freopen() is not giving
>>> application full control over internal buffer allocation and we need to be
>>> sure we lock-in memory for critical section - and some glibc versions are
>>> allocating buffers here via 'mmap' call.
>>>
>>> That said - there could be accepted a patch checking in configure for
>>> 'read-only' stdin - and using then #ifdef compilation that would
>>> replace use of internal lvm2 reopen code with libc function.
>>
>> I had a suspicion you would have a good reason.
>>
>> On first glance your proposal sounds like a good compromise and one
>> that would be worth exploring.
>
> As an alternative idea, what about changing the codebase not to use
> stdin/stdout/stderr, using it's own file descriptor names and calling
> dup2() as appropriate to set them up on startup ?
>
> Just flying the kite - I haven't looked to see how painful this might be.
Hi
Well don't know anyone who would play with this approach which is several
orders in magnitude more difficult then the plain and simple #ifdef.
I also assume we may probably even overwrite value of stdin via tricky pointer
magic so compiler will not be able to spot mods of stdin in buildtime.
Regards
Zdenek
WARNING: multiple messages have this Message-ID (diff)
From: Zdenek Kabelac <zkabelac@redhat.com>
To: lvm-devel@redhat.com
Subject: MUSL fun
Date: Sat, 13 Feb 2016 22:36:20 +0100 [thread overview]
Message-ID: <56BFA1D4.20105@redhat.com> (raw)
In-Reply-To: <CA+BsyQ5Lhvys2eea64T_qE49DaE7gH6QEPsAFi+Nn7VfJ_Ourw@mail.gmail.com>
Dne 13.2.2016 v 22:31 Brendan Heading napsal(a):
>>> There is a reason from lvm2 implementation here - freopen() is not giving
>>> application full control over internal buffer allocation and we need to be
>>> sure we lock-in memory for critical section - and some glibc versions are
>>> allocating buffers here via 'mmap' call.
>>>
>>> That said - there could be accepted a patch checking in configure for
>>> 'read-only' stdin - and using then #ifdef compilation that would
>>> replace use of internal lvm2 reopen code with libc function.
>>
>> I had a suspicion you would have a good reason.
>>
>> On first glance your proposal sounds like a good compromise and one
>> that would be worth exploring.
>
> As an alternative idea, what about changing the codebase not to use
> stdin/stdout/stderr, using it's own file descriptor names and calling
> dup2() as appropriate to set them up on startup ?
>
> Just flying the kite - I haven't looked to see how painful this might be.
Hi
Well don't know anyone who would play with this approach which is several
orders in magnitude more difficult then the plain and simple #ifdef.
I also assume we may probably even overwrite value of stdin via tricky pointer
magic so compiler will not be able to spot mods of stdin in buildtime.
Regards
Zdenek
next prev parent reply other threads:[~2016-02-13 21:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-15 16:43 MUSL fun Brendan Heading
2016-02-13 18:48 ` Bernd Kuhls
2016-02-13 19:22 ` [Buildroot] [lvm-devel] " Brendan Heading
2016-02-13 19:22 ` Brendan Heading
2016-02-13 21:02 ` [linux-lvm] [lvm-devel] " Zdenek Kabelac
2016-02-13 21:02 ` Zdenek Kabelac
2016-02-13 21:19 ` [Buildroot] [lvm-devel] " Brendan Heading
2016-02-13 21:19 ` Brendan Heading
2016-02-13 21:19 ` [linux-lvm] [lvm-devel] " Brendan Heading
2016-02-13 21:31 ` [Buildroot] " Brendan Heading
2016-02-13 21:31 ` Brendan Heading
2016-02-13 21:31 ` [linux-lvm] [lvm-devel] " Brendan Heading
2016-02-13 21:36 ` Zdenek Kabelac [this message]
2016-02-13 21:36 ` Zdenek Kabelac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56BFA1D4.20105@redhat.com \
--to=zkabelac@redhat.com \
--cc=buildroot@uclibc.org \
--cc=linux-lvm@redhat.com \
--cc=lvm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.