DragonFlyBSD

Hi Justin,

Which DF version is that? We have a stub mlockall() in master but I
think it is not MFC'ed to 2.6.
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/5b6d478465a99af56589ef42d9f7a5d90d9adce4

With master:

mlockall: Function not implemented

Cheers,
Antonio Huete

2010/6/12 Justin C. Sherrill <justin@shiningsilence.com>:

pulseaudio stopped building on 2.6/i386/pkgsrc-2010Q1 - here's the error:

http://avalon.dragonflybsd.org/reports/i386/2.6/20100612.1126/pulseaudio-0.9.21nb2/build.log

Can anyone else build it successfully?  I haven't seen it as a problem
(yet) in the other builds, which makes me suspicious.

On Sat, June 12, 2010 5:11 pm, Antonio Huete Jimenez wrote:

Hi Justin,

Which DF version is that? We have a stub mlockall() in master but I
think it is not MFC'ed to 2.6.
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/5b6d478465a99af56589ef42d9f7a5d90d9adce4

With master:

./t_ml

mlockall: Function not implemented

Is it worth MFC'ing? I have a vague feeling I had talked to someone about
this before, but I can't find evidence of it.

:>> ./t_ml
:> mlockall: Function not implemented
:
:Is it worth MFC'ing? I have a vague feeling I had talked to someone about
:this before, but I can't find evidence of it.

What direction are we talking about?  Making it return ENOSYS or
   making it return success but otherwise be a NOP ?

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Hi,

As it is not really implemented I think ENOSYS is more appropiate. But
definitely the best thing at all is to implemented it :P

Cheers,
Antonio Huete

2010/6/13 Matthew Dillon <dillon@apollo.backplane.com>:

:>> ./t_ml
:> mlockall: Function not implemented
:
:Is it worth MFC'ing?  I have a vague feeling I had talked to someone about
:this before, but I can't find evidence of it.

  What direction are we talking about?  Making it return ENOSYS or
  making it return success but otherwise be a NOP ?

                                       -Matt
                                       Matthew Dillon
                                       <dillon@backplane.com>

On Sun, June 13, 2010 12:41 am, Matthew Dillon wrote:

:>> ./t_ml
:> mlockall: Function not implemented
:
:Is it worth MFC'ing? I have a vague feeling I had talked to someone
about
:this before, but I can't find evidence of it.

What direction are we talking about? Making it return ENOSYS or
making it return success but otherwise be a NOP ?

Whichever makes it build on 2.6. I don't know which that is. I'm a bit
suspicious, because I don't remember pulseaudio breaking on 2.6/x86_64.

On Sun, Jun 13, 2010 at 3:50 AM, Antonio Huete Jimenez
<ahuete.devel@gmail.com> wrote:

Hi,

As it is not really implemented I think ENOSYS is more appropiate. But
definitely the best thing at all is to implemented it :P

Cheers,
Antonio Huete

2010/6/13 Matthew Dillon <dillon@apollo.backplane.com>:

:>> ./t_ml
:> mlockall: Function not implemented
:
:Is it worth MFC'ing?  I have a vague feeling I had talked to someone about
:this before, but I can't find evidence of it.

  What direction are we talking about?  Making it return ENOSYS or
  making it return success but otherwise be a NOP ?

                                       -Matt
                                       Matthew Dillon
                                       <dillon@backplane.com>

--
Cheers,
Antonio Huete

Returning ENOSYS is correct as per the specification.

The mlockall() and munlockall() functions will fail if:

[ENOSYS]
The implementation does not support this memory locking interface.

See: http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html

Sam

On 6/13/2010 15:52, Samuel J. Greear wrote:

On Sun, Jun 13, 2010 at 3:50 AM, Antonio Huete Jimenez
<ahuete.devel@gmail.com> wrote:

Hi,

As it is not really implemented I think ENOSYS is more appropiate. But
definitely the best thing at all is to implemented it :P

Cheers,
Antonio Huete

2010/6/13 Matthew Dillon<dillon@apollo.backplane.com>:

:>> ./t_ml
:> mlockall: Function not implemented
:
:Is it worth MFC'ing? I have a vague feeling I had talked to someone about
:this before, but I can't find evidence of it.

What direction are we talking about? Making it return ENOSYS or
making it return success but otherwise be a NOP ?

-Matt
Matthew Dillon
<dillon@backplane.com>

--
Cheers,
Antonio Huete

Returning ENOSYS is correct as per the specification.

The mlockall() and munlockall() functions will fail if:

[ENOSYS]
The implementation does not support this memory locking interface.

See: http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html

Yeah, well, that's SUSv2...

However, see the change history here:

http://www.opengroup.org/onlinepubs/9699919799/functions/mlockall.html

Sascha

Justin C. Sherrill wrote:

Can anyone else build it successfully? I haven't seen it as a problem
(yet) in the other builds, which makes me suspicious.

you can ifdef out this portion within pulseaudio..

I'm waay late on those patches I promised.. but yeah..

am staying online to get them done before world cuppage

GOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL!

Chris Turner wrote:

you can ifdef out this portion within pulseaudio..

Broken patch attached - Couldn't quite figgure out the correct
preprocessor macros to make this 'clean' - my actual build
used '#ifdef notyet' like some other things in main.c

In any event, we now have a 'mlockall' on head -
so probably need to see if this is even necessary
moving forward before trying to get it upstream,
unless anyone wants to get fancy with their 'ifdef's
and make it version specific

On 6/15/2010 11:32, Chris Turner wrote:

Chris Turner wrote:

you can ifdef out this portion within pulseaudio..

Broken patch attached - Couldn't quite figgure out the correct
preprocessor macros to make this 'clean' - my actual build
used '#ifdef notyet' like some other things in main.c

In any event, we now have a 'mlockall' on head -
so probably need to see if this is even necessary
moving forward before trying to get it upstream,
unless anyone wants to get fancy with their 'ifdef's
and make it version specific

Actually, the proper fix would be to make pulseaudio check with
sysconf(3) for _SC_MEMLOCK, to see if the implementation supports it. In
our case, it would then quickly see that we don't, as we return -1.

Regards,
Sascha

Okay, I'm grabbing this.

Hi all,

The problem here seems that despite pulseaudio checks it correctly or not, it
won't change the fact that we need stubs to avoid the 'unresolved symbols' at ld
time. After investigating this a bit I think it's okay by now to leave our stubs
returning ENOSYS so any call to the functions will simply fail.

BTW, we have utilities now in base using (cryptsetup) referencing
mlockall/munlockall.

In the mean time the fix has been MFC'ed so pulseaudio will likely build in 2.6
RELEASE also. We'll see in the next round of bulk builds.

Cheers,
Antonio Huete

We have stubs everywhere now, correct? So this can be closed?

On Thu, September 9, 2010 10:18 pm, Samuel J. Greear \(via DragonFly issue
tracker\) wrote:

Samuel J. Greear <sjg@evilcode.net> added the comment:

We have stubs everywhere now, correct? So this can be closed?

I think so - it builds on i386/2.7. It failed in my most recent
x86_64/2.7 build but that was an indirect failure because of m4.