On Thu, 5 Dec 2002, Allen Akin wrote:
>
> Putting it in "kernel guy" terms, it's like sideband mechanisms for
> talking to device-dependent code in the kernel that bypass the syscall
> interface. A few such things exist for special purposes, but do you
> advocate using them as the normal way to make wholesale changes in the
> behavior of end-user apps?
But that's the point - we do have a lot of these, and they are supremely
convenient exactly _because_ apps mostly don't care.
In a kernel world, the "sideband signals" are things like mount options:
they often affect the behaviour of the whole filesystem, but in ways that
apps don't care about (they may be _visible_ to the app, don't get me
wrong - things like interruptible NFS mounts, specific permission masks
etc, but it is all about making something uniformly visible to different
programs _without_ having to teach each and every program about some
specific thing).
Or imagine "nice" levels and resource limits. All in-kernel "sideband
information" that the app can usually query, but most of the time it ends
up being just a policy that 99% of all applications just don't care about.
And every single ioctl is a "special sideband" thing. Some are generic and
work for all file descriptors, some work for certain types of files, and
some are very hw-dependent. They are often very inconvenient (and I
absolutely _detest_ some of them), but there's no way they can be
generally removed, exactly because the kernel absolutely _needs_ ways to
by-pass just the normal "everything is a stream of bytes" approach.
As a very (simple) example of something that is actually similar, think
about something like "setterm" on the text console. It's all sideband
information - most programs just use "write()" to write to the screen, and
the colours chosen etc are all in the sideband information that was done
by things _outside_ the program that writes the text.
(This used to be more true, these days a lot of programs are color-aware.
Too many, in my opinion, but I'm oldfashioned).
Linus
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
