Re: Migrating to larger numbers
Nathan Hand (nathanh@chirp.com.au)
Wed, 9 Jun 1999 09:57:58 +1000
On Wed, Jun 09, 1999 at 08:20:26AM +1000, Richard Gooch wrote:
> Nathan Hand writes:
> > On Tue, Jun 08, 1999 at 12:16:40PM +0200, Pavel Machek wrote:
> > > Actually, gpm is probably going to be trashed and replaced with kernel
> > > approach (because in-kernel input drivers mean better sharing
> > > etc.). XF86_SVGA already has its fbcon counterparts (like
> > > creatorfb).
> >
> > This is a side issue I'd like to discuss.
> >
> > Kernel side abstraction of mouse drivers is painful. It encourages
> > user space applications that take over the entire device, and this
> > prevents applications from sharing a device.
> >
> > The perfect example is /dev/dsp. Because the interface was "fairly
> > good" applications chose to open(2) it. So your desktop could make
> > noises, but you had to kill your desktop to play an mp3.
> >
> > This has led to the current mess with your choice of ESD, OSS, and
> > ALSALIB as the sound API. If applications had used the theoretical
> > libsound.so from the start, there wouldn't be this problem.
>
> I'm not advocating a kernel-based gpm, but it seems to me that the
> problem you mention with sound is due to the device semantics. The
> kernel doesn't impose single-open rules. That's a fault of the driver.
But there's no reason for /dev/dsp to do mixing. The mixing should be
done in user space anyway (it's a complex issue, possibly involving a
number of data streams, with different levels, from networks or local
disk, and the user may want to filter the mixed output before the dsp
gets hold of it anyway).
> You could just as easily make the same mistake in libsound.so.
But you can easily replace libsound.so. It's harder to fix /dev/dsp.
I'd much rather keep the existing mess of /dev/psaux, /dev/ttyS0, and
all the weird bus mice. Some libmouse.so can then provide the cleanly
abstracted interface. And guess what, the library exists, it's called
libgpm.so. If programs use libgpm.so directly then the kernel doesn't
need to abstract the mouse interface.
Unless there is a technical reason why the kernel has to abstract the
mouse interface. I can't see one, but that doesn't mean much.
--
Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
Phone: +61 2 6230 1871 Fax: +61 2 6230 4455 E-mail: nathanh@chirp.com.au
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/