On Tue, 2008-09-23 at 14:47 +0200, Lennart Poettering wrote: > On Tue, 23.09.08 14:38, Ralf Corsepius (rc040203@xxxxxxxxxx) wrote: > > > > > On Tue, 2008-09-23 at 14:21 +0200, Lennart Poettering wrote: > > > On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski (dominik@xxxxxxxxxxxxxx) wrote: > > > > > Oh my. So you know someone who thinks that ioctl()s are ingenious API > > > design? > > What do ioctls and files/stream not provide that you are missing? > > > > ioctls essentially are "descriptor"/"tag"/"arbitrary argument". > > An interface can hardly be more generic than this. > > Yes, and the fact that it is that generic is the weakness. > > You know, we have this wonderful language called C. It's all about > tape-safety and having nice names for things and having proper > signatures for functions and being descriptive. ioctl()s go against > all that. They are not type-safe, have unreadable names, have no > signatures and are everthing but descriptive. > > Let's say every single libc call would have been mutlipexed by a > single function call. i.e. instead of calling malloc() like this: > > a = malloc(4711); > > you'd call: > > a = (void*) libc(LC_MLLC, 4711); > > Now think of hwo your program would look like in its entirety: > unreadable. Absolutely crazy and unreadable. > > Now ioctl() does exactly this: a vast number of function calls are > multiplexed via a single function call. Big fuckup. And everyone who > claims that that would be good API design is just wrong, really, > really wrong. It's not good. It's a fuckup. It's terrible. And I tell you: You are wrong, plain wrong. ioctl's are a well defined _low level_ interface, providing a clean and "natural" separation between kernel and userspace. To make them easily applicable in high-level userspace applications, they are supposed to be wrapped. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
