Re: Configuration of the RGA200 communication baud rate

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

Request for discussion:

Instead of forcing the line rate to 9600 in drvAsynSerialPortConfigure() how about just leaving it at the value already configured.  Then applications that need some rate not supported by termios can set the rate (somehow) before IOC startup and ensure that the st.cmd script has no calls to set the line rate.

It would be better if this could be controlled by an ‘option/flags’ argument to drvAsynSerialPortConfigure, but as far as I can tell we’ve never documented the “default 9600 baud” anywhere so we wouldn’t be changing any explicitly-defined existing behaviour.

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