On Wednesday 14 September 2022 10:58:48 Johan Hovold wrote: > On Wed, Sep 14, 2022 at 10:48:31AM +0200, Pali Rohár wrote: > > On Tuesday 13 September 2022 16:59:22 Johan Hovold wrote: > > > On Thu, Aug 18, 2022 at 04:09:52PM +0200, Pali Rohár wrote: > > > > On Sunday 24 July 2022 15:08:09 Johan Hovold wrote: > > > > > On Sun, Jul 24, 2022 at 02:59:08PM +0200, Pali Rohár wrote: > > > > > > On Sunday 24 July 2022 14:54:58 Johan Hovold wrote: > > > > > > > On Sun, Jul 24, 2022 at 02:33:51PM +0200, Pali Rohár wrote: > > > > > > > > > > > > > What is updated is the real baudrate in c_ispeed and c_ospeed > > > > > > > > extensions. > > > > > > > > > > > > > > > > It is really wrong? I thought that c_cflag should stay unchanged at > > > > > > > > B38400 when ASYNC_SPD_CUST is used. > > > > > > > > > > > > > > Yeah, cflags stay unchanged, but you shouldn't touch those fields when > > > > > > > using the deprecated ASYNC_SPD_CUST hack. > > > > > > > > > > > > Hm... Why? I thought that new extended fields (c_ispeed and c_ospeed) > > > > > > should contain current real speed. What is the reason that c_*speed > > > > > > fields should have 38400 when ASYNC_SPD_CUST hack is set? > > > > > > > > > > Because we shouldn't go adding new features built around the deprecated > > > > > ASYNC_SPD_CUST hack. > > > > > > > > But this is not a new feature in the old deprecated hack. It for the > > > > new interface. > > > > > > I think I understand what you're getting at, but no. Let's not add more > > > features built around ASYNC_SPD_CUST. > > > Seems that you did not understand the point. So I will try to explain it > > again. This is not a new feature for _old_ ASYNC_SPD_CUST. This is the > > fix for the _new_ TCGETS2 API, to ensure that driver will always returns > > corrects values in c_*speed fields. If driver is not going to fix this > > _new_ TCGETS2 API then there is _NO_ point to use this new API in > > userspace and it is better to stick with the old ASYNC_SPD_CUST. And > > this is the current userspace state. So based on your input, it is the > > time to deprecate TCGETS2? > > Stop being silly. As I've said repeatedly, we don't care about > ASYNC_SPD_CUST. Just return 38400 regardless of whatever magic happens > behind the scenes with the TIOCSSERIAL ioctl. > > Johan I'm not silly here. Look, those APIs are for userspace. And if userspace application cannot use this new TCGETS2 API (for more reasons) then they stick with the old one TIOCSSERIAL. And your inputs just say that it is not a good idea to switch TCGETS2 as this API stay broken in some drivers. Silly is the one who do not see (or do not want to see it; because of own API perfectionism) the reasons why new "proposed API" is still not (widely) used and applications stick with TCGETS + TIOCSSERIAL. That is why I'm asking, it is time to starting deprecating TCGETS2 and create for example TCGETS3? Only just few application use TCGETS2, so deprecation of TCGETS2 can be done _now_ without pain as this API is not widely used.
