Radim Krčmář <rkrcmar@xxxxxxxxxx> writes: > 2015-02-27 17:14+0100, Vitaly Kuznetsov: >> This series converts kvp/vss daemons to use misc char devices instead of >> netlink for userspace/kernel communication and then updates fcopy to be >> consistent with kvp/vss. >> >> Userspace/kernel communication via netlink has a number of issues: >> - It is hard for userspace to figure out if the kernel part was loaded or not >> and this fact can change as there is a way to enable/disable the service from >> host side. > > (Hm, this should be just a message to the userspace daemon, but netlink > probably makes it complicated anyway.) > >> Racy daemon startup is also a problem. > > (Is it significantly worse than what we need to protect devices?) > >> - When the userspace daemon restarts/dies kernel part doesn't receive a >> notification. > > (True, we could use a other-side-closed callback.) With normal devices we can use e.g. udev/systemd machinery to start/stop service on device hotplug/hotunplug (and these devices are actually pluggable/unpluggable from host side) without any special code in kernel/userspace parts and I'd like to use that. > >> - Netlink communication is not stable under heavy load. > > (The message order changes?) > It is a disaster if it does (the whole transaction will get lost). Same if any of these messages gets lost. >> RFC: I'm a bit puzzled on how to split commits 1 and 2 avoiding breakages. > > Split the userspace part -- it won't break bisects. > Sure if it simplifies the review. > And then, you could refactor drivers first ... the way we communicate > with userspace should have little impact on what the rest does (or how). > At first sight, there are three units, apart from glue, > 1) communication with host > 2) communication with userspace > 3) repacking of data between first two > > With an API for userspace communication, the amount of code to replace > netlink could be lower and resulting patches definitely easier to > review. (And with extra work, both ABIs could even live side-by-side ;) Ok, thanks! -- Vitaly _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
