Configfs vs ioctl [LWN.net]

Configfs vs ioctl

Posted Aug 26, 2005 15:50 UTC (Fri) by farnz (guest, #17727)
In reply to: Configfs vs ioctl by giraffedata
Parent article: Configfs - an introduction

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.

(Log in to post comments)

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.