Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Interesting. If this replaces ioctl() completely, then perhaps it (and the BKL) could finally go away
Configfs - an introduction
Posted Aug 25, 2005 6:41 UTC (Thu) by bronson (subscriber, #4806)
ConfigFS might allow migrating slowly off ioctls, of course, but that is years away. The BKL doesn't really get in the way anymore, does it?
Posted Aug 25, 2005 8:07 UTC (Thu) by farnz (guest, #17727)
Posted Aug 25, 2005 9:42 UTC (Thu) by daniel (subscriber, #3181)
Not it isn't, an ioctl goes straight through to the kernel without interpretation.
"and have glibc do the ConfigFS magic when ioctl is called"
What a perfectly horrible idea. Ioctls are lightweight, configfs is anything but. Configfs is for people. You can echo MySetting >/config/MySystem/frobme. For a program, it is a lot of pointless work opening the file, formatting the parameter, writing to it, closing it. An ioctl is one or two lines.
Posted Aug 25, 2005 9:51 UTC (Thu) by farnz (guest, #17727)
If you want to replace ioctl with ConfigFS, this is the obvious transition plan. If you don't want to do so, then of course the transition plan's a bad idea.
Posted Aug 25, 2005 18:45 UTC (Thu) by elanthis (guest, #6227)
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.
Posted Aug 25, 2005 19:24 UTC (Thu) by farnz (guest, #17727)
Configfs vs ioctl
Posted Aug 26, 2005 15:37 UTC (Fri) by giraffedata (subscriber, #1954)
Posted Aug 26, 2005 15:50 UTC (Fri) by farnz (guest, #17727)
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.
Posted Aug 26, 2005 20:18 UTC (Fri) by giraffedata (subscriber, #1954)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds