Recent Features
| |||||||||||||
Configfs vs ioctlConfigfs vs ioctlPosted Aug 26, 2005 15:37 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: Configfs - an introduction by farnz Parent article: Configfs - an introduction 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?
(Log in to post comments)
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.
|
|||||||||||||