Re: Configuration of the RGA200 communication baud rate

[Charter via Tech-talk <tech-talk at aps.anl.gov>]

Also, see https://www.downtowndougbrown.com/2013/11/linux-custom-serial-baud-rates/

John

On Jan 13, 2026, at 3:52 PM, Eric Norum via Tech-talk <tech-talk at aps.anl.gov> wrote:

I'm inclined to agree.  Adding a bunch of kernel/platform-specific ifdef’s to drvAsynSerialPort.c isn’t very appealing.

My first thought at a workaround was to suggest invoking an iocsh ’system’  command to run a python program to set the line rate after all calls to asynSetOption.

This *might* work as long as read timeouts never change — changing a read timeout results in a call to tcsetattr() which would overwrite the speed set by the python program.  Pretty fragile, though.

Or perhaps there’s a way to enable 28.8kbaud in the kernel and thus in termios.h?  The ASYN driver will allow this speed if it’s present in termios.h.

On Jan 13, 2026, at 12:09 PM, J. Lewis Muir <jlmuir at imca-cat.org> wrote:

On 01/13, Érico Nogueira Rolim via Tech-talk wrote:

Just something to note if anyone wishes to use that post as reference (and the recent glibc support isn't enough). It mentions an issue with including kernel headers:

I ran into some #include hell with asm/termios.h, especially if I already had the normal termios.h included elsewhere, so you might have to copy relevant struct definitions into your own code if you can’t get it to work (I know, nasty!). The other thing to keep in mind is that the definition of NCCS might be different between your libc and kernel, so you need to make sure you’re using the kernel’s definition of NCCS. I believe asm/termbits.h has the correct NCCS and structures defined.

The kernel docs explicitly recommend copying struct definitions into userspace code that uses syscalls/ioctls directly. That way you can be sure of what version is in use, and you can name structs appropriately in order to avoid any conflicts. This can get messy if the kernel definitions vary by architecture, and then violating that recommendation becomes more reasonable, so I hope that's not the case.

?? Sounds like a terrible idea to me.  If kernel-related structs are
needed from userspace, the OS should provide appropriate header files
defining those that are either shared by userspace and kernelspace thus
ensuring that they're consistent, or, if separate sets for userspace and
kernelspace, are at least guaranteed to be consistent with each other.

Lewis

— 

Eric Norum

eric at norum.ca