Hi Bjorn, > >> > This is preparing for supporting devices using other > >> > protocols than AT commands. Such devices will typically not > >> > echo back the received command. > >> > > >> > Signed-off-by: Bjørn Mork <bjorn@xxxxxxx> > >> > --- > >> > This won't affect existing users. I was wondering how to enable > >> > echo in a sane way. I did not want to that the tty route using > >> > an ioctl... Although that is probably the only possible way > >> > if configuring this is required per client? > >> > > >> > For now it is a static device specific attribute. The assumption > >> > is that QMI devices will have this on to enable monitoring complete > >> > transactions from a read-only process, while AT based devices have > >> > it turned off as they echo back commands themselves > >> > >> This makes me wonder why we want to work around user space's > >> stupidity of not knowing what it sent. > > > > actually we do not even want this. Especially not for a binary protocol > > like QMI. It is pretty much a really bad idea. > > Why? > > Echo is explicitly enabled only for QMI speaking interfaces for now. I > agree that enabling it unconditionally for any unknown protocol is a bad > idea. > > But as long as we know the transported protocol is QMI, then we also > knows that it includes both response/request/notification flags and > source of the packet. Any application will need to filter out the > packets it wants anyway, and if you only want to see them in one > direction then you filter on e.g (sender != 0x80) > > The reason for wanting echo is to enable applications monitoring both > outgoing and incoming packets, which are extremely useful for debugging > and development of the real user space applications. I believe having > this feature will help user application development a lot, and having it > from the beginning will ensure that no-one believes they can get away > with no filtering. this is not how application protocols are designed. And we do not even need this for debugging. You think that you do right now, because it makes your life initially easier (and I understand that), but it is actually total waste. In the long term none of this will be needed. There will be only one entity controlling your QMI device anyway. If you wanna have multiple applications using QMI, you still need to multiplex them via one central daemon. And this is normally your telephony stack that takes full control over the device. So something like oFono or even ModemManager has to manage the QMI device. <snip> > >> However, this seems to be a traditional capability of ttys. And the other > >> major option to configure wireless devices is a pseudo serial interface. > >> That on the gripping hand argues for doing this exactly the way a tty does > >> it, namely by supporting the very ioctl ttys use. > > > > For AT commands, this is a feature of the hardware itself. And not some > > TTY or kernel magic. And we actually switch echoing off since nobody > > ever gets this right. Not even for AT commands. > > > > So again, a really really bad idea. > > I suspect that you are thinking along the lines that there should be > only one single application using this device at the time. The fact is > that there is no need to enforce such restrictions. The device supports > dealing with multiple clients (hence the client ID registration scheme), > and it can be very useful not having to integrate all your > network/SMS/call management/monitoring stuff in a single complex > application. These ideas sound all fun and nice, but in reality it does not really work this way. You are going to have one single application controlling the device. I know this is not obvious in the beginning and everybody makes it look like SMS has nothing to do with call management and network registration and so on, but plain fact it is all entangled. The client ID schema and its registration per service domain that Qualcomm uses is also pointless since that is more a reflection of how the modem firmware is internally structured (it reflects the internal tasks of their realtime OS) than it actually means anything on Layer 4 and above. If you do not believe me, then have a look into oFono and see how things like SIM file system access, call handling, network registration and GPRS are entangled. They look separate and to some level we can make applications believe that, but underneath there is a lot of stuff going on where essentially we have to deal with all service domains anyway. > Would you want wireshark to only show you the incoming packets? Wireshark could just sniff the USB transport in Linux. I would actually prefer that since then it can nicely also capture the network packets as well. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
