On Sun, 10 May 2020 at 17:46, Scott Allen via talk <talk@gtalug.org> wrote:
On Sun, 10 May 2020 at 17:30, Karen Lewellen via talk <talk@gtalug.org> wrote:
for example if the program would talk to a serial device on com 4, how would you achieve the same goal via a USB to serial adapter?
Under Linux, serial ports are named as "files" under the /dev directory, usually starting with tty. Real serial ports are usually name ttySx (with x being a number. USB serial ports are usually named ttyUSBx, or sometimes ttyACMx if it identifies as a modem type device.
However, there are ways to give a device any name you like based on its model, manufacturer, serial number or other identifying parameters that the device provides.
This is something where Once Upon a Time, things were very different. These days, device names are generated dynamically in /dev when a device comes online. Once Upon a Time, if you added a serial port, there would not be a device in /dev until you ran /bin/mknod with suitable arguments to put it there. I recall having to do so back when I did an upgrade to add a fast UART (14550 or 16550 I think); the new serial port did not appear automatically like it would today. Here is a wikipedia page with some of the relevant history: https://en.wikipedia.org/wiki/Device_file#Naming_conventions My mention of /bin/mknod dates back to the days before Linux 2.3, when dinosaurs roamed the earth :-) In 2.3.6, a first edition of dynamic device naming appeared, loosely based on Solaris conventions (so my memory tells me). That was when the fighting began, in many ways not unlike the fights surrounding systemd, and for some of the same reasons. The old-timers knew that they knew better what they wanted their devices names to be than some newfangled mechanism written by some arrogant upstart. That's where the fighting occurs. (With systemd and with the Gooch devfs implementation from around the year 2000.) Of course, there are also reasonable arguments as to why the operating system should be managing more of this for us. They actually are common reasons: we WANT some automation of managing devices because, with modern buses like USB, and network devices, we now plug in new devices frequently, and would like them to just work. devfs was a service for handling the automatic attachment of devices to file nodes in /dev systemd is at least partly about having policies for attaching devices to software services so that USB drives are accessible to users once plugged in and so network services appear at appropriate times too. The notion of using /bin/mknod to manually manage where devices go seems very quaint in 2020. In 2001, that was very much a present fight between people with varying positions on the matter. It's an interesting, albeit somewhat off-topic question, how FreeDOS handles this. I don't think FreeDOS went through the "devfs" evolutionary process which covered a LOT of kinds of devices on Linux. I'd expect FreeDOS to do one of two things: a) Number the ports physically (by some measure) so you need to pick COM1, COM2, COM3, and perhaps guess which is which b) Offer some command loosely similar to /bin/mknod to let you configure COM ports. A web search finds a thread on an HP web site: https://h30434.www3.hp.com/t5/Desktop-Operating-Systems-and-Recovery/RS232-S... The parts of that which seem informative point at FreeDOS having a command/program called MODE that seems to be how you configure COM ports. Here is a link to MODE, which I think might be helpful. http://wiki.freedos.org/wiki/index.php/Mode -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"