On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote: > >> SO_OOBINLINE does not control the delivery of signal, It controls how > >> OOB Byte is delivered. It may not be obvious but this change does not > >> deliver any Byte, just a signal. So, as long as sendmsg flag contains > >> MSG_OOB, signal will be delivered just like it happens for TCP. > > Not as far as I can read this code. If MSG_OOB is set the data from the > > message used to be discarded, and EOPNOTSUPP returned. Now the data gets > > queued to the socket, and will be read inline. > > Data was discarded because the flag was not supported, this patch > changes that but does not support any urgent data. When you say it does not support any urgent data do you mean the message len must be == 0 because something is checking it, or that the code does not support its handling? I'm perfectly fine with the former, just point me at the check, please. > OOB data has some semantics that would have to be followed and if we > support SO_OOBINLINE we would have to support NOT SO_OOBINLINE. > > One can argue that we add a socket option to allow this OR just do what > TCP does.
