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