Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Adam Tlałka]

Dnia 10-01-2006 o 15:17:21 Jaroslav Kysela <perex@xxxxxxx> napisał:

> On Tue, 10 Jan 2006, Hannu Savolainen wrote:
>
> > On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
> >
> > > >
> > > > Then you can include a libOSSlib.o library in ALSA with all the OSS
> > > > emulation stuf inside.
> > >
> > > You should do the clear statement that the direct using of syscalls  
> > is not
> > > recommented for application developers. Unfortunately at this time, I
> > > admit, it would be very difficult to change the existing applications.
>
> > Sorry. That breaks backward compatibility with systems that don't have
> > libOSSlib (all current and past Linux distros, all BSD variants,
> > everything but systems with our official OSS package installed). Such
> > statement can be added in 2010 but provided that all Linux distros and
> > other environments having OSS compatible implementations add the  
> > osslib_*
> > routines within this year.
>
> I meant that you can originate to move the OSS entry point to somewhere
> else (library) and try to persuade developers to use library than direct
> calls.
>
> Of course, we cannot change current applications, but we can start the
> movement now. I just ask you to do it now. Nothing else. It will be a  
> slow
> process but it should be started now.
>
> Also, I don't think that it will break something. The application
> developers can use your code in their applications directly when the
> distribution does not have the OSS access library package.
 ger atlka@xxxxxxxxxxxxxxxxx

Doing every call through some lib even if it's only a wrapper leading
to kernel syscall doesn't look very interesting.
Some people need statically lined apps and minimum usable distro without
bloated libs. What about Unix device abstraction?
Are we going the current Windows way?

Anyway Windows is stearing to the microkernel approach (approaching Vista)
and it looks that we are going to the current Windows model while MS  
developers
are going far away. Hurd looks nice but it is not good enough now.
But the idea is good and needs more people to improve it.

So we could have Unix device approach with drivers running as separate  
processes
not in kernel space. With proper kernel scheduling and being non-swappable
we could get good security, stability and additionally enough simple
from app point of view approach. Going through libs we are going through
all the LD_PRELOAD and LD_LIBRARY_PATH and linker security hell.

Kernel approach looks good enough for me now. But it is not so secure of  
course.
So we need some process->kernel-device->driver RT/non-swappable/correctly
scheduled process IPC so we can do it the other way. IMHO that's the future
if we don't want drivers in the kernel.

Best regards
--
Adam Tlałka      mailto:atlka@xxxxxxxxx    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@xxxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/