| |||||||||||||
Configfs - an introductionConfigfs - an introductionPosted Aug 25, 2005 18:45 UTC (Thu) by elanthis (guest, #6227)In reply to: Configfs - an introduction by farnz Parent article: Configfs - an introduction
It's a library call that is often inlined (possibly by specialized compiler support), isn't it?
I tend to be in a minority, but so far as I'm concerned, *any* breakage of *any* user-space application (that isn't doing something unsupported/undefined by the official call interface) is a serious problem. I shouldn't be required to recompile my user-space software to upgrade core components to fix bugs or security holes, ever.
(Log in to post comments)
Configfs - an introduction Posted Aug 25, 2005 19:24 UTC (Thu) by farnz (guest, #17727) [Link] So you do it over a long time if the aim is to phase out ioctl(2). Phase 1 is to update glibc and friends to do the translation, together with a moratorium on new ioctls. Phase 2, some time later, is to provide a kernel option to disable ioctl(2), so that people can see if their software is broken. Phase 3, a couple of years later, is to disable that option by default. Finally, phase 4 is to remove ioctl(2) once no-one uses it.
Configfs vs ioctl Posted Aug 26, 2005 15:37 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I can't see how you could ever phase out ioctl via this strategy. libc (and generic parts of the kernel) have no idea what the argument to ioctl means. Individual device drivers and filesystem drivers assign meaning to it. That's the major reason ioctls are used. Would you put cases for every known use of ioctl in libc? And even if you did, how would libc know which language the particular ioctl is in?
Configfs vs ioctl Posted Aug 26, 2005 15:50 UTC (Fri) by farnz (guest, #17727) [Link] That's exactly what you'd do; one case for each ioctl goes into the library, translating the ioctl to a ConfigFS access. This allows you to use ConfigFS instead of ioctl.I don't understand the language comment; how does the kernel do it now? I thought it got a set of binary values from userspace, which it acted on. This code could be moved into the runtime libraries for all languages that provide ioctl access, converting the binary values into text for ConfigFS, which the kernel would then convert back to the binary values it would have acted on. Let me emphasise again that this is only what you'd do if you'd already decided to phase out ioctl for ConfigFS. There's no reason why you can't do this change, but lots of reasons why you shouldn't.
Configfs vs ioctl Posted Aug 26, 2005 20:18 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Let me emphasise again that this is only what you'd do if you'd already decided to phase out ioctl for ConfigFS. I agree that this is the best way given that you are replacing ioctls with configfs. The obvious inference from the fact that you brought it up in response to a concern about backward compatibility is that you're saying it could be a practical way to get backward compatibilty; so I'm trying to show that it's not practical, so the backward compatibilty objection to configfs has to stand. As long as we agree there's no practical way to get backward compatibility, I have no dispute.
... one case for each ioctl goes into the library I don't think anyone would accept that. I don't understand the language comment; how does the kernel do it now? I thought it got a set of binary values from userspace, which it acted on. It also gets a file descriptor, which has a lot of context with it. In particular, it tells the kernel which ioctl handler to call, and that ioctl handler knows what language (protocol) the argument is in. libc would have to be hacked really hard to have it track open file state and know which open files go with with device/file types.
|
|||||||||||||