Date: Sat, 16 Jun 2007 14:46:05 -0600 From: Scott Long <scottl@samsco.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Ariff Abdullah <ariff@FreeBSD.org>, Joel Dahl <joel@FreeBSD.org> Subject: Re: cvs commit: src/sys/dev/sound version.h src/sys/dev/sound/pci es137x.c src/sys/dev/sound/pcm buffer.c channel.c channel.h dsp.c dsp.h feeder.c feeder_rate.c mixer.c mixer.h sndstat.c sound.c sound.h vchan.c src/sys/dev/sound/usb uaudio.c Message-ID: <46744C0D.4050208@samsco.org> In-Reply-To: <20070616223202.12ac7a46@deskjail> References: <200706160337.l5G3bTd8066242@repoman.freebsd.org> <1182023759.1243.4.camel@localhost> <20070616223202.12ac7a46@deskjail>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Leidinger wrote: > Quoting Joel Dahl <joel@FreeBSD.org> (Sat, 16 Jun 2007 21:55:59 +0200): > >> On Sat, 2007-06-16 at 03:37 +0000, Ariff Abdullah wrote: >>> ariff 2007-06-16 03:37:29 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/dev/sound version.h >>> sys/dev/sound/pci es137x.c >>> sys/dev/sound/pcm buffer.c channel.c channel.h dsp.c dsp.h >>> feeder.c feeder_rate.c mixer.c mixer.h >>> sndstat.c sound.c sound.h vchan.c >>> sys/dev/sound/usb uaudio.c >>> Log: >>> - New sysctl: "hw.snd.compat_linux_mmap" to allow PROT_EXEC page >>> mapping, due to recent changes in linux compatibility layer which >>> require it. All linux applications that using sound + mmap() (mostly games) >>> require this to be enabled. Disabled by default. >> So, sound on several Linux applications (I guess games for the most >> part, like you said) is broken by default now? > > No, it is broken since the linux_mmap changes (since some months). > > I would like to see this problem solved without the need to change a > sysctl. > > Ariff, what does this do? It seems it only changes the sound part, and > not any other linux mmapped region. So what is the impact of allowing > this by default and removing the sysctl? > One way to fix this that I've discussed already with Ariff is to have each proc be marked with the ABI that is it running in. I need that for another driver that has a linux-compat issue, and I think it would be good in the long run to be able to determine 32 vs 64 bit processes as well as processes that are coming from a special-need (aka linux short-bus) ABI. I'm hoping to lock Peter and John in a conference room next week and not let them come out until something is resolved here =-) Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46744C0D.4050208>