Dnia 10-01-2006 o 15:17:21 Jaroslav Kysela <[email protected]> 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 [email protected]
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:[email protected] ^v^ ^v^ ^v^
System & Network Administration Group ~~~~~~
Computer Center, Gdańsk University of Technology, Poland
PGP public key: finger [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
