Hi there,
On Sat, Feb 15, 2003 at 06:59:47PM +0100, Abramo Bagnara wrote:
> We might call this thread "the neverending misunderstanding" ;-)
;-)
> My message was a proposal about an universal solution for
> control/out-of-band streams on pseudo-files (like the Linus sig fd,
> devices fd, socket, proc files, etc.) as a way to comunicate between
> user space and kernel space.
>
> I.e. something that might replace ioctl/fcntl mess giving same (and
> more) flexybility and power (extending the 'everything is a file'
> concept also to control data).
>
> This is *not* something I'd propose for user space (where we definitely
> have many good ways to achieve these results).
So you propose channels that are defined ONLY by the kernel? That
would make much more sense and could replace ioctl/fcntl indeed,
if we add one more syscall: sys_transact().
long transact(int fd, const void *request_buffer, const size_t request_size,
void *result_buffer, const size_t result_size);
This syscall works like read/write with some exceptions:
(Basis features)
- short reads/short writes are not allowed
- EINTR will not happen.
- the effects done to the fd and the underlying object must be
undone if the request will fail
- it is optional (file operation) and can return -1/errno=ENOSYS,
if not implemented by the underlying kernel object.
- supplying (fd, NULL, 0, NULL, 0) checks for existence (NOP).
(Advanced features)
- supplying (fd, REQUEST, sizeof(REQUEST), MAP_FAILED, 0)
returns the expected return buffer size for this request (or
zero, if no result will be returned). May return -ENXIO, if
this checking is not supported or -EINVAL, if that request
is not supported by the underlying kernel object.
- supplying (fd, REQUEST, sizeof(REQUEST), NULL, 0)
is issueing a request without a result (e.g. a COMMAND) or
telling that the user is not interested in any detailed
results (that variant might be supported by the kernel object or not)
- The two buffers might alias partially or as a whole.
With that additional semantic we could replace all ioctl() too,
where an ioctl() is used only to get this semantic.
Other OSes have an ioctl() mechanism like that syscall and we
implement it by destroying the argument in IORW-ioctls.
With that in place, I could live without ioctl() and fcntl().
That would also destroy all the interfaces that require you to
read after a write, because it needs transaction semantics
(sg.c comes to mind).
Regards
Ingo Oeser
-- Science is what we can tell a computer. Art is everything else. --- D.E.Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:15 EST