On Fri, Dec 11, 2020 at 09:46:54AM +0100, Jiri Slaby wrote: > On 10. 12. 20, 19:59, Mychaela Falconia wrote: > > > O_DIRECT is an interesting hack, has anyone seen if it violates the > > > posix rules for us to use it on a character device like this? > > > > According to open(2) Linux man page, O_DIRECT does not come from POSIX > > at all, instead it is specific to Linux, FreeBSD and SGI IRIX. Thus > > it seems like there aren't any POSIX rules to be violated here. > > > > If we go with O_DIRECT, what semantics are we going to implement? > > There are 3 possibilities that come to mind most readily: > > > > 1) O_DIRECT applies only to the open call in which this flag is set, > > and suppresses DTR/RTS assertion on that open. If someone needs to do > > multiple opens with DTR/RTS suppression being required every time, > > then they need to include O_DIRECT every time. > > > > 2) O_DIRECT applies not only immediately, but also sets a latched flag > > whereby all subsequent opens continue to suppress auto-assertion > > without requiring O_DIRECT every time. This approach by itself runs > > counter to the generic Unix way of doing things, but it may be OK if > > there is also some ioctl to explicitly set or clear the latched flag. > > > > 3) O_DIRECT applies only to the open call in which it is set, no > > built-in latching, but there is also some ioctl to control a flag > > enabling or disabling DTR/RTS auto-assertion on subsequent opens. > > 3) -- to allow standard tools to work on the device after the quirk is set > up once. I'm lost, what do you mean here? thanks, greg k-h
