Re: Switching from IOCTLs to a RAMFS

Re: Switching from IOCTLs to a RAMFS

[Peter Chubb]

>>>>> "Jeff" == Jeff Garzik <jgarzik@pobox.com> 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

Re: Switching from IOCTLs to a RAMFS

[Jeff Garzik]

Peter Chubb wrote:

>>>>>>"Jeff" == Jeff Garzik <jgarzik@pobox.com> 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.
>  
>


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)

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 28 Oct 2002 11:18, Jeff Garzik wrote:
<stuff about posix_devctl() snipped>
> 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-----