On 07.12.20 14:52, Michael S. Tsirkin wrote: >> See above: NAK. because it can't even be enabled directly (by the user). >> If it wasn't meant otherwise, we'd have to add an menu text. > > The point is that user enables one of the bindings. > That in turn enables drivers. If we merely select VIRTIO > there's a chance user won't remember to select any bindings > and will be surprised not to see any devices. Not sure what you mean by "bindings" ... transports ? IMHO, transports and device drivers are entirely orthogonal. Both *use* the core, but I don't think they shall only show up, after the core was enabled explicitly. Any combination of transports is valid (having none at all, of course, isn't actually useful). >> When using other transports ? > > Any transport selects VIRTIO so if you enable that, you get > VIRTIO and thus it's enough to depend on it. The combination of 'select VIRTIO' and 'depends on VIRTIO' is what caused the recursive dependency. Chaning everything to 'select VIRTIO' fixed that. >> I don't thinkt that would be good - instead everybody should just select >> VIRTIO, never depend on it (maybe depend on VIRTIO_MENU instead) > > GPU depends on VIRTIO and on VIRTIO_MENU ... which seems even messier > ... See: https://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg2404871.html --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287