Apologies for re-ordering your comments, but I thought it might make my reply more clear.
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? | 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. Ioctls are closely analogous to OpenGL API calls: Some of them work on pretty much any type of file (like OpenGL core commands work on pretty much any rendering context) and some of them are hardware dependent (like OpenGL extension commands tend to be). But ioctls *don't* bypass the syscall interface; they use the main process-to-kernel communication channel, not a sideband mechanism. So they're not the sort of special case that I had in mind when I made the comment quoted above. | 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). In the graphics world, some analogous things might be options that control what Visual types the X11 server advertises, or what framebuffer configurations are supported. These things have a few centralized points of control, just like mount options, and they pretty much apply to all apps. The semantics are part of the graphics APIs, just like filesystem semantics are part of the corresponding kernel APIs. Is there an environment variable you can set that changes whether a single process sees a filesystem as mounted read-only? If not, then mount options don't seem like a good analogy for the sort of sideband communication we're considering adding to the graphics drivers. | 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). The current color for the console is global state, and all the programs using write() to a console device know that, so they're aware that it can change asynchronously and they have to deal with that possibility. Programs that don't deal with it are not well-written, and if something goes wrong they're at fault. The current texture-filtering parameters (for example) are local state (local to a texture object), and the OpenGL specification actually says what the initial values have to be. Apps are aware of that, and many of them rely on it either explicitly or implicitly. If you create a mechanism that overrides what the OpenGL spec guarantees, some apps will continue to work, and some won't -- even if they're well-written. It may not be obvious whether the app is at fault. There's a *lot* of low-level graphics state in a desktop system, and there's a *huge* number of possible failure modes in a nontrivial app like a game. Keep in mind that on Windows most games shut down the window system entirely, and one of the main reasons is to cut down on the number of ways things can fail. (Particularly resource allocations.) Throughout this discussion, most people have been assuming that failures are unlikely, so there's a good win from building a mechanism that overrides what the OpenGL spec guarantees. In my experience, failures ranging from minor to disastrous are surprisingly likely, so I don't think there'll be nearly as much win as some people expect. I'd rather we spent our time on something more productive. But to make this constructive, I think the best thing we can do is to generate a list of the state that people want to tweak. There's a lot of low-level state, so it could be a *very* long list. Once it exists, we'll have a better idea of how much work is involved, folks who are new to OpenGL can learn about the ways in which those things can misbehave, and we can decide whether the additional costs of implementation and handling difficult-to-reproduce bugs are worth it. Allen ------------------------------------------------------- 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
