2015-03-03 10:53+0100, Vitaly Kuznetsov: > Radim Krčmář <rkrcmar@xxxxxxxxxx> writes: > > 2015-02-27 17:14+0100, Vitaly Kuznetsov: > >> Re-implement the communication using misc char device. Use ioctl to do > >> kernel/userspace version negotiation (doesn't make much sense at this moment > >> as we're breaking backwards compatibility but can be used in future). > > > > The ioctl is used too creatively for my liking: as an out-of-band > > communication that is required after the main channel has been opened. > > It would be simpler to inject the version into first x bytes of the > > stream, making a read() after open() mandatory. > > We need to perform a handshake - kernel part sends its version and > receives daemon's version. (We could also design a backward-compatible protocol, which should be possible for an application this simple, but keeping options is wise.) > We can definitelly pack everything in the > data stream but why do we need to avoid ioctls? I think it is better if the kernel sends its version (set of features) first, so it would be just a simple two-way handshake. Kernel-initiated communication is not possible over ioctl and it doesn't give extra options for handshake either. > It seems to me the > handshake we're performing here belongs to a 'control' stream, not > 'data' stream. Handshake makes sense after we open the device and before any 'data' can appear on it, so multiplexing the same carrier also prevents a lot of stupid cases, like ioctls from different applications. Not to mention that asynchronicity itself has a fairly bad record. (I don't really understand the difference between 'control' and 'data'.) -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
