Switching from IOCTLs to a RAMFS
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Jeff" == Jeff Garzik <[email protected]> writes:
Jeff> Like I touched on in IRC, there is room for both sysfs and per-driver Jeff> filesystems.
Jeff> I think just about everyone agrees that ioctls are a bad idea and a huge Jeff> maintenance annoyance.
I note that the P1003.26 ballot has just been announced...
Title: P1003.26: Information Technology -- Portable Operating System Interface (POSIX) -- Part 26: Device Control Application Program Interface (API) [C Language]
Scope: This work will define an application program interface to device drivers. The interface will be modeled on the traditional ioctl() function, but will have enhancements designed to address issues such as "type safety" and reentrancy.
It may be worth looking at what the draft standard says before committing to yet another interface specification.
Peter C
Quoted 22 lines · Peter Chubb
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
"Jeff" == Jeff Garzik <[email protected]> writes:
Jeff> Like I touched on in IRC, there is room for both sysfs and per-driver Jeff> filesystems.
Jeff> I think just about everyone agrees that ioctls are a bad idea and a huge Jeff> maintenance annoyance.
I note that the P1003.26 ballot has just been announced...
Title: P1003.26: Information Technology -- Portable Operating System Interface (POSIX) -- Part 26: Device Control Application Program Interface (API) [C Language]
Scope: This work will define an application program interface to device drivers. The interface will be modeled on the traditional
ioctl()function, but will have enhancements designed to address issues such as "type safety" and reentrancy.
Quoted 4 lines
It may be worth looking at what the draft standard says before committing to yet another interface specification.
Already looked at it. It's awful, and retains many of the problems that ioctl(2) presents to kernel maintainers.
I sent a comment in to the only email address I could find describing the issues (politely!), but as a mere peon I doubt it will have much effect. The best we can do is ignore this POSIX junk and hope it goes away...
Jeff
Kernel/userspace interfaces (was: Switching from IOCTLs to a RAMFS)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 28 Oct 2002 11:18, Jeff Garzik wrote:
<stuff about posix_devctl() snipped>
Quoted 4 lines
I sent a comment in to the only email address I could find describing the issues (politely!), but as a mere peon I doubt it will have much effect. The best we can do is ignore this POSIX junk and hope it goes away...
I'd like something more positive than "hope it goes away"... :-)
This allows me to do my irregular "does anyone care about the kernel ABI / API definition?" song'n'dance.
Currently we use standard unix semantics - char devices, block devices, sockets, etc. However there is no definition for what that interface actually does. We have (most of ?) SUSv3, but there are a lot of other things we're doing. Some (many?) of the features aren't getting used because:
1. Not known by userspace programmers.
2. Non-standard semantics and no tutorial / example material.
3. Random changes to features and lack of versioning.
We also have serious problems with management of header files. "Use the headers that came with your glibc" misses ioctl() definitions, which are inherently kernel interfaces, not glibc interfaces.
I'll again offer to moderate a BoF, at LCA (http://www.linux.conf.au) in Perth. I don't have anything like the answers, so its only worth doing if someone with a clue is interested. LCA BoFs don't have much time or many slots, so if there's a decent amount of interest, it might be worth doing on the Tuesday (say for a couple of hours, in the vacant third mini-conf slot).
Does anyone care?
Brad
- --
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9vOvBW6pHgIdAuOMRAtmAAKCCb1eWxksZpiVNPjFYERC+79sWSwCgv4a5 RbtwYjH9COJbhKwqBw22hyI=
=HW49
-----END PGP SIGNATURE-----