[linux-lvm] [lvm-devel] MUSL fun
zkabelac at redhat.com
Sat Feb 13 21:02:55 UTC 2016
Dne 13.2.2016 v 20:22 Brendan Heading napsal(a):
> [cc buildroot]
> Like you I'd been investigating this issue from the buildroot end.
> Since October I've had no spare time to look at buildroot fixes.
> I was hoping for an explanation about why LVM implemented the above
> behaviour, but I never got one, and I didn't fancy working on a patch
> that would never get accepted when other projects were more open ..
> I think the best approach is probably just to add the freopen() patch
> as Romain suggested and keep the patch available in buildroot in the
> hope that we can build support for LVM to accept it.
> On 13 February 2016 at 18:48, Bernd Kuhls <bernd.kuhls-zqRNUXuvxA0b1SvskN2V4Q at public.gmane.org> wrote:
>> Am Tue, 15 Sep 2015 17:43:58 +0100 schrieb Brendan Heading:
>>> In theory a straightforward fix would be to do something like:
>>> if (!freopen(NULL, "r", stdin))
>>> goto out;
>>> .. but I suspect there is a good reason why this isn't done. Can anyone
>>> shed any light on this ? If not I will submit a patch.
>> Hi Brendan,
>> the buildroot project also supports musl, the build of lvm2 fails due to
>> the problem you described. Did you find a working solution for the
>> problem? A patch I submitted to the buildroot project, based on patches I
>> found at the Alpinelinux project, raised some questions I am unable to
>> answer: http://patchwork.ozlabs.org/patch/573519/
>> Regards, Bernd
Let's start from the beginning -
commands/toolcontext.c: In function 'create_toolcontext':
commands/toolcontext.c:1796:10: error: assignment of read-only variable 'stdin'
stdin = new_stream;
So now - from where comes the idea of 'stdin' being read-only variable ?
Looking at some POSIX spec e.g.:
there is no sign of having this read-only var.
So what kind of OS this actually is ?
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.
But the currently posted patch may possibly cause some other regressions.
More information about the linux-lvm