In article <[EMAIL PROTECTED]> you write:
>On Sun, 13 Feb 19100, Andrey Novikov wrote:
>
>> > You probably want to increase either SEMMNI or SEMMNS.
>>
>> I've noticed that but why are they so "round"? Is there any corelation
>> between all these numbers? I don't want to break my kernel by guessing.
>>
>> > > options SEMMAP=31
>> > > options SEMMNI=11
>> > > options SEMMNS=61
>> > > options SEMMNU=31
>> > > options SEMMSL=61
>> > > options SEMOPM=101
>> > > options SEMUME=11
>
>I ran into this problem when I was trying to compile and use a useful
>Linux audio application and I got the ENOSPC error.
>...
>Now, I'd like to contribute the hacking and bugfixing I've done on
>the linux bplay program to someone for review and possible inclusion
>as a port, but if it doesn't work with the supplied kernel and generic
>config, I'm not sure what the correct action for me to take would be.
hmm bplay, this is probably the original source that was used with
some changes for gramofile, for which i already just submitted a
port... (ports/16819, there its called play_gramo.) i simply
patched it to use FreeBSD's default number.
(If its not committed yet try the query-pr.cgi, or searching for
gramofile in *freebsd.ports* on deja.com should also turn it up.)
>
>Is there a good reason not to tweak the GENERIC/LINT FreeBSD kernel
>config SEM* definitions upwards to something that will allow the bplay
>to work out-of-the-box^H^H^Hport?
so its not necessary for bplay, the only justification for this
i could think of would be to be able to run linux binaries without
recompiling...
>
>Or should there just be a huge <BLINK>warning</BLINK> that appears
>when building bplay advising that certain kernel parameters may need
>tuning before the program has a chance of working, during the
>compilation/installation, or just somewhere in the ports files where
>it can be ignored?
>
>
>Otherwise, I can't see that bplay would be particularly useful as a
>port, but rather as additional software the user could optionally
>choose to hunt down and install...
>
no even if a port won't work with the default kernel for some
reason its still useful as a port, tho it probably should then have
a pkg/MESSAGE telling the admin what he needs to put into the kernel.
HTH,
--
Juergen Lock <[EMAIL PROTECTED]>
(remove dot foo from address to reply)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
