Re: [lldb-dev] [llvm-dev] RFC: Code Review Process
Forgive me if I'm wrong, but if the community consensus is that we should continue to use Phabricator, and Phabricator is not being provided/maintained by the LLVM Foundation, isn't it moot what the LLVM Foundation/Infrastructure Working Group recommends/wants to happen? The current maintainers would continue to maintain Phabricator (assuming they wanted to), and people would still be able to review things there. What would happen if the Foundation officially supported PRs, without community consensus (in particular from the Phabricator maintainers), is a potential split in the community, with some continuing in the old way and others using the new way (and presumably some choosing to review on both platforms). This cannot be good. I'm all for the discussion to be had, about whether we switch, but as far as I can see, nothing's really changed from the previous conversations on PRs versus Github, apart from the announcement of end of support by the upstream company, but that was quite a while ago now, and even with the stale Arcanist issue, there hasn't been a big push from community members to change: the consensus in the posts discussing this and the moving to PRs seems to still be "there are things that are blocking switching still". At the most, from this IWG/Foundation consultation, it should be that the Foundation recommends one or other approach, and is willing to provide X infrastructure required. The community can then choose to agree with whatever approach is recommended or stick with the status quo. There shouldn't be an edict that says we will do one thing or the other. Another side-point: whilst the IWG may consist of people who care about LLVM, there are far more people who care as much, but who just don't have the time to participate in such a group. This is particularly important to note, because the community does not elect members to this group. To an extent, the same is also true of the Foundation board itself, since there are plenty of people who may not agree with their decisions, but don't have the time to volunteer for the board. I'm not suggesting that there's any malice in this discussion, and indeed, the fact that it's open to community comments certainly is helpful, but I'd be worried of some kind of echo chamber/unconscious bias within the small groups suggesting there is consensus for one approach, when the wider community thinks otherwise. James On Tue, 5 Oct 2021 at 20:52, Tanya Lattner via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hello! The purpose of this email is to start a discussion about our code > review tools. No decisions have been made about changing tools. The idea > behind a timeline is so that information could be gathered in a timely > manner. The Infrastructure Working Group was formed to bring together > community members who have an experience and/or passion regarding > infrastructure. Anyone can participate in this working group and like the > LLVM Foundation, the minutes are all made public. > > The LLVM Foundation’s mission is to support the LLVM project and help > ensure the health and productivity of of the community and this is done > through numerous ways including infrastructure. I do not think it is a > negative thing that the foundation board of directors would be discussing > our current tools and gathering information how how well they work and how > we can make them better. As the legal entity who bares financial and legal > responsibility for a lot of the infrastructure, this would make sense. This > also makes sense because of the people involved who care a lot about LLVM > and the project. But, the LLVM Foundation does not pay for Phabricator and > we are very grateful for Google’s support of this critical piece of our > infrastructure. > > Regarding Phabricator, there are a couple of pieces of information that > were provided to the LLVM Foundation by maintainers (maybe previous it > sounds like) of this instance and how we may need to look into alternative > ways to support it. In addition, Phacility itself has publicly stated that > it is winding down operations. ( > https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/). > Lastly, there are questions about why we are not using GitHub pull requests > as we are on GitHub and that might be the natural path to take for a number > of reasons. > > The above reasons are why the RFC was written. Perhaps it wasn’t written > in the best way, but I also feel like it is being read in a negative way > which is incredibly disappointing given I don’t feel there is a valid > reason for this. > > -Tanya > > > > > > > On Oct 5, 2021, at 11:35 AM, Renato Golin via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > On Tue, 5 Oct 2021 at 19:16, Tom Stellard wrote: > >> However, it's not a good position for the Board to be responsible >> for something that it doesn't have control over. If Google decided to >> stop hosting >> Phabricator for some reason (unlikely, but not
Re: [lldb-dev] Serial port support in LLDB
Thanks for the nice summary Michał. I've found it very helpful. The thing I am missing from this proposal is how would those settings translate into actual termios calls? Like, who would be responsible reading those settings and acting on them? Currently we have some tty code in ConnectionFileDescriptorPosix (in the Host library) but I think a bit too low-level for that (I don't think the host library knows anything about "settings"). I am also not sure if a class called "ConnectionFileDescriptor" is really the best place for this. On 05/10/2021 11:21, Michał Górny via lldb-dev wrote: Hi, everyone. I'm working on improving LLDB's feature parity with GDB. As part of this, I'm working on bettering LLDB's serial port support. Since serial ports are not that common these days, I've been asked to explain a bit what I'd like to do. At this point, LLDB (client) has minimal support for serial port debugging. You can use a command like: process connect file:///dev/ttyS0 to connect via the GDB Remote Protocol over a serial port. However, the client hardcodes serial transmission parameters (I'll explain below). I haven't been able to find an option to bind lldb-server to a serial port. I'd like to fix the both limitations, i.e. make it possible to configure serial port parameters and add support for serial port in lldb-server. The RS-232 standard is quite open ended, so I'm going to focus on 8250- compatible serial port with DB-9 connector below (i.e. the kind found in home PCs). However, I'm going to skip the gory details and just focus on the high-level problem. The exact protocol used to transmit data over the serial port is configurable to some degree. However, there is no support for autoconfiguration, so both ends have to be configured the same. The synchronization support is also minimal. The important hardware parameters that can be configured are: - baud rate, i.e. data transmission speed that implies the sampling rate. The higher the baud rate, the shorter individual bits are in the transmitted signal. If baud rate is missynced, then the receiver will get wrong bit sequences. - number of data bits (5-8) in the frame, lower values meaning that the characters sent are being truncated. For binary data transfers, 8 data bits must be used. I believe gdb-remote protocol is compatible with 7-bit connections, though we would need to make sure lldb refrains from using some packets. Should I take it this is not an avenue you wish to pursue? - parity used to verify frame correctness. The parity bit is optional, and can be configured to use odd or even parity. Additionally, Linux supports sending constant 0 or 1 as parity bit. - number of stop bits (1 or 1.5/2) in the frame. The use of more than one stop bit is apparently a relict that was supposed to give the receiver more time for processing. I think this one isn't strictly necessary nowadays. Gotta love those half-bits. - flow control (none, software, hardware). This is basically used by the receiver to inform the sender that it's got its buffer full and the sender must stop transmitting. Software flow control used in-band signaling, so it's not suitable for binary protocols. Hardware flow control uses control lines. Of course, there is more to serial ports than just that but for LLDB's purposes, this should be sufficient. The POSIX and win32 API for serial ports are quite similar in design. In the POSIX API, you have to open a character device corresponding to the serial port, while in win32 API a special path \\.\COMn. In both cases, reads and writes effect the transmission. Both systems also have a dedicated API to configure the serial transmission parameters (ioctl/termios on POSIX [1], DCB on win32 [2]). Note that I haven't tried the win32 API, just looked it up. The POSIX serial ports are a teletype (tty) devices just like virtual consoles used by terminal emulators. This makes it easy to use a serial port as a remote terminal for other system. This also adds a bunch of configuration options related to input/output processing and special behavior. When a serial port is going to be used for non-console purposes, these flags have to be disabled (i.e. the tty is set to 'raw' mode). The rough idea is that after opening the serial port, we need to set its parameters to match the other end. For this to work, I need to replace LLDB's hardwired parameters with some way of specifying this. I think the cleanest way of doing this (and following GDB's example) would be to add a new set of configuration variables to specify: a. the baud rate used b. the parity kind used c. the number of stop bits d. whether to use hardware flow control I'm thinking of creating a new setting group for this, maybe 'host.serial'. When connecting to a serial port, LLDB would set its parameters based on the settings from this group. That said, I can't think of a really clean way
Re: [lldb-dev] Serial port support in LLDB
On Wed, 2021-10-06 at 14:32 +0200, Pavel Labath wrote: > Thanks for the nice summary Michał. I've found it very helpful. > > The thing I am missing from this proposal is how would those settings > translate into actual termios calls? Like, who would be responsible > reading those settings and acting on them? Currently we have some tty > code in ConnectionFileDescriptorPosix (in the Host library) but I think > a bit too low-level for that (I don't think the host library knows > anything about "settings"). I am also not sure if a class called > "ConnectionFileDescriptor" is really the best place for this. > > On 05/10/2021 11:21, Michał Górny via lldb-dev wrote: > > Hi, everyone. > > > > I'm working on improving LLDB's feature parity with GDB. As part of > > this, I'm working on bettering LLDB's serial port support. Since serial > > ports are not that common these days, I've been asked to explain a bit > > what I'd like to do. > > > > > > At this point, LLDB (client) has minimal support for serial port > > debugging. You can use a command like: > > > > process connect file:///dev/ttyS0 > > > > to connect via the GDB Remote Protocol over a serial port. However, > > the client hardcodes serial transmission parameters (I'll explain > > below). I haven't been able to find an option to bind lldb-server to a > > serial port. > > > > I'd like to fix the both limitations, i.e. make it possible to configure > > serial port parameters and add support for serial port in lldb-server. > > > > > > The RS-232 standard is quite open ended, so I'm going to focus on 8250- > > compatible serial port with DB-9 connector below (i.e. the kind found > > in home PCs). However, I'm going to skip the gory details and just > > focus on the high-level problem. > > > > The exact protocol used to transmit data over the serial port is > > configurable to some degree. However, there is no support for > > autoconfiguration, so both ends have to be configured the same. > > The synchronization support is also minimal. > > > > The important hardware parameters that can be configured are: > > > > - baud rate, i.e. data transmission speed that implies the sampling > >rate. The higher the baud rate, the shorter individual bits are > >in the transmitted signal. If baud rate is missynced, then > >the receiver will get wrong bit sequences. > > > > - number of data bits (5-8) in the frame, lower values meaning that > >the characters sent are being truncated. For binary data transfers, > >8 data bits must be used. > I believe gdb-remote protocol is compatible with 7-bit connections, > though we would need to make sure lldb refrains from using some packets. > Should I take it this is not an avenue you wish to pursue? No, I don't think that there's a good reason to pursue it. GDB itself doesn't support 7-bit connections (i.e. forces 8 bits unconditionally), so I doubt that there's a point in doing that. > > > > > - parity used to verify frame correctness. The parity bit is optional, > >and can be configured to use odd or even parity. Additionally, Linux > >supports sending constant 0 or 1 as parity bit. > > > > - number of stop bits (1 or 1.5/2) in the frame. The use of more than > >one stop bit is apparently a relict that was supposed to give > >the receiver more time for processing. I think this one isn't > >strictly necessary nowadays. > Gotta love those half-bits. Fortunately, 8250 support half-bits only with 5-bit data frames, so we can forget about them entirely ;-). > > > > > - flow control (none, software, hardware). This is basically used by > >the receiver to inform the sender that it's got its buffer full > >and the sender must stop transmitting. Software flow control used > >in-band signaling, so it's not suitable for binary protocols. > >Hardware flow control uses control lines. > > > > Of course, there is more to serial ports than just that but for LLDB's > > purposes, this should be sufficient. > > > > > > The POSIX and win32 API for serial ports are quite similar in design. > > In the POSIX API, you have to open a character device corresponding to > > the serial port, while in win32 API a special path \\.\COMn. In both > > cases, reads and writes effect the transmission. Both systems also have > > a dedicated API to configure the serial transmission parameters > > (ioctl/termios on POSIX [1], DCB on win32 [2]). Note that I haven't > > tried the win32 API, just looked it up. > > > > The POSIX serial ports are a teletype (tty) devices just like virtual > > consoles used by terminal emulators. This makes it easy to use a serial > > port as a remote terminal for other system. This also adds a bunch of > > configuration options related to input/output processing and special > > behavior. When a serial port is going to be used for non-console > > purposes, these flags have to be disabled (i.e. the tty is set to 'raw' > > mode)
Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Code Review Process
Since I think we're risking confusion on the point here, let me clarify that at least my response to this thread should not be read as opposition (or support) for a migration to github. I am expressing no opinion on that matter. I see the primary point being discussed in this thread being the decision making process proposed, not the decision itself. Philip On 10/6/21 10:26 AM, Chris Tetreault via llvm-dev wrote: > … nothing's really changed from the previous conversations on PRs versus Github, apart from the announcement of end of support by the upstream company, but that was quite a while ago now, and even with the stale Arcanist issue, there hasn't been a big push from community members to change … James, If you’ll forgive me for cherry-picking a small part of your point, I think it bears mentioning that human beings tend to ignore future problems until they become current problems. Most of us here want to work on compilers, not deal with infrastructure. This doesn’t mean that the status quo is ok. As I see it, it would be a mistake to just continue on with zombie-phabricator as we have. Perhaps the board of directors could have taken a different tone when presenting this issue, but I think they are doing the right thing by forcing a change soon. Tools are degrading, and security fixes are not being implemented. If we do nothing we’re all going to wake up some day and find that the github repo has had its owner changed or somesuch catastrophe. We need to do **something**, and I think setting a deadline for a change was the right call. From my perspective, there are 4 reasonable things we can do, in order of disruptiveness: 1. Investigate a community replacement for phabricator. Does Phorge meet our needs? Is there a maintained fork of phabricator? Can we just drop in some replacement? 2. Fork Phabricator, and take on the maintenance burden ourselves. This sounds like work. 3. Move to github PRs. As others have mentioned, there are pros and cons to this. 4. Something else? We’d have to figure out what this is, and justify it over options 1-3. If the deadline the board has set is unpalatable to the community, then perhaps it makes sense to fork Phabricator, and then decide on a longer term migration plan. But we need to do something and we need to do it now, not when there’s an actual fire. Personally, I like Phabricator, and find github PRs to be tedious to work with. If we went with github PRs, I would be able to work, but I would prefer something more like phabricator. thanks, Chris Tetreault *From:* cfe-dev *On Behalf Of *James Henderson via cfe-dev *Sent:* Wednesday, October 6, 2021 1:47 AM *To:* Tanya Lattner *Cc:* llvm-dev ; Renato Golin ; clang developer list ; openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev *Subject:* Re: [cfe-dev] [llvm-dev] RFC: Code Review Process *WARNING:*This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Forgive me if I'm wrong, but if the community consensus is that we should continue to use Phabricator, and Phabricator is not being provided/maintained by the LLVM Foundation, isn't it moot what the LLVM Foundation/Infrastructure Working Group recommends/wants to happen? The current maintainers would continue to maintain Phabricator (assuming they wanted to), and people would still be able to review things there. What would happen if the Foundation officially supported PRs, without community consensus (in particular from the Phabricator maintainers), is a potential split in the community, with some continuing in the old way and others using the new way (and presumably some choosing to review on both platforms). This cannot be good. I'm all for the discussion to be had, about whether we switch, but as far as I can see, nothing's really changed from the previous conversations on PRs versus Github, apart from the announcement of end of support by the upstream company, but that was quite a while ago now, and even with the stale Arcanist issue, there hasn't been a big push from community members to change: the consensus in the posts discussing this and the moving to PRs seems to still be "there are things that are blocking switching still". At the most, from this IWG/Foundation consultation, it should be that the Foundation recommends one or other approach, and is willing to provide X infrastructure required. The community can then choose to agree with whatever approach is recommended or stick with the status quo. There shouldn't be an edict that says we will do one thing or the other. Another side-point: whilst the IWG may consist of people who care about LLVM, there are far more people who care as much, but who just don't have the time to participate in such a group. This is particularly important to note, because the community does not elect members to this group. To an extent, the same is
