[GTALUG] Actual ttyS0 MIA

[Christopher Browne]

On Sun, 10 May 2020 at 17:46, Scott Allen via talk <talk at gtalug.org> wrote:

> On Sun, 10 May 2020 at 17:30, Karen Lewellen via talk <talk at 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-Serial-Communications-via-FreeDOS-is-not-working/td-p/6585759

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?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20200510/54b07935/attachment.html>