On Thu, Dec 05, 2002 at 05:38:41PM -0800, Linus Torvalds wrote: > > > > 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).
But those affect all applications, which is a Bad Thing. > 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. Yes, and it's the individual applications which call those ioctl()s, not a kernel-wide configuration which affects all programs. There's certainly no way for an ioctl() to affect some applications and not others without the individual applications making those ioctl()s, in any case. > 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. Yes, but setterm affects all subsequent applications being run from that terminal, and that same mechanism applied to DRI would affect all subsequent applications being run from that driver instance. I could see a configuration program talking to the driver directly to give it that sideband information, and that would be somewhat acceptable (and not all that different from how Windows does it), but then that still has the problem of someone running a quick game of Quake before going back to their CAD work. -- http://trikuare.cx ------------------------------------------------------- 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
