0

A word of caution regarding this question: I'm more a userland than kernel person but have this nagging concern which I think belongs to kernel.

When configuring a system one decides on peripherals and assigns various tty's accordingly. Occasionally one had to consult termcaps and select or insert an entry for getty to use.

The procedure was similar for character and block devices, and if I recall also extended to graphics terminals with frame buffers.

The termcaps file was large and populated by all previously known and many obsolete terminal types.

And all these devices plugged and played once assigned correctly, including SCSI disk units.

Then came USB, and I noticed that open source kernels add them outside of termcaps, and mostly not plug-and-play, with each flavor of the unices needing a highly idiosyncratic procedure to plug and finally play.

Question would these (especially the USB mass storage devices) not have been p-n-p configurable through termcaps, as I notice that at least in OpenBSD, they simply join the kernel through assigned SCSI ports?

Related issue - I understand that Dennis Ritchie at AT&T enhanced stdio with streams to support hot swap plug-and-play (SysV), and if so would it not be possible to implement something similar in conjunction with termcaps to ease USB userland support on unices?

Improve this question
7
  • 3
    Could you clarify what you think termcap has to do with storage devices?
    – Stephen Kitt
    Dec 9, 2019 at 14:01
  • 1
    @StephenKitt, Perhaps there is some confusion with printcap?
    – Ray Butterworth
    Dec 9, 2019 at 14:20
  • 1
    @Ray maybe, but AFAIK printcap doesn’t have anything to do with storage devices either, does it? There are SCSI and USB printers, but the question doesn’t mention those (“SCSI disk units”, “USB mass storage devices”).
    – Stephen Kitt
    Dec 9, 2019 at 14:27
  • 1
    @StephenKitt, no, as far as I've seen (and that's like 50 years), termcaps are strictly for describing terminal capabilities. Printcaps have a similar syntax and usage and describe printer capabilities. I've never heard of a similar "*cap" for storage devices other than specific device drivers, which are code in a somewhat standardized form, not data files.
    – Ray Butterworth
    Dec 9, 2019 at 14:35
  • I gave you an upvote for your perfect latin declination of Unix -> Unices :)
    – Gunther Schadow
    Dec 10, 2019 at 4:57

2 Answers 2

Reset to default
10

The role of Termcap in contemporary Unix-style systems is the same as it always has been: it provides a library and database allowing software to adapt to the varying capabilities of different terminals.

These terminals can be physical (connected to a serial port, typically) or virtual, provided by any one of a number of terminal emulators (the console on Unix-style systems, or a GUI terminal emulator, or tmux, or screen, or PuTTY...).

None of this concerns mass storage devices, whatever the way they are connected.

Nowadays however, Terminfo is more commonly-used than Termcap.

Improve this answer
1
  • I'd also recommend reading The TTY demystified by Linus Åkesson. A good understanding of how the TTY system works and its history is essential to understanding what termcap and terminfo are and are not, and how they fit into modern unixes.
    – ssokolow
    Dec 19, 2019 at 3:59
5

Erm. I think here are a few misunderstandings at work.

Termcap is a descriptional database about terminal features (*1), not device configurations.

In sense of Unix terminals aren't devices, but something connected to a device. In a more general sense, Unix-devices are (*2) interfaces that can be accessed using OS measures.

It may be this basic mixup between the use of 'Device' as a generic term for some physical ... well ... device, with the notation of 'Device' in Unix. So for now, lets call them physical-device and Unix-device.

Termcap describes an application layer used on top of communication via a Unix-device for example a serial interface - but others are possible as well. The operating system doesn't care about termcap in particular or terminal functions at all. Only device parameters are handled by the driver - and not part of termcap. All it handles is I/O to/from the Unix-device. Obeying/using termcap (or not) is up to either application, which includes (hopefuly) the shell in use.

SCSI and USB are not terminals, but devices. They are handled as such by device drivers. Termcap has, as said, no role.

It feels like the question is more about device drivers than terminals or termcaps, and here about some imagined standard. There is none. The way to do so under Unix are device drivers, and they are a breed of hermits.

In sense of Unix-devices, SCSI and even more so USB are a bit special, as both are designed by default to handle a wide variety of physical-devices, concurrent, using the same interface. So this calls for layered model. A basic driver handling the USB host controller and on top drivers for either physical-device connected (*3).

And that's were one point were all the various ways of implementations come in, as some argue that handling such physical-devices is a userland issue, while others prefer device drivers to do so. It gets complicated by the fast that many of them are already known to the system under other aspects, thus it is desirable to have them look like earlier incarnations - like a USB-Serial interface plugged to USB producing a TTY device entry instead of having to be handled by some user land library.

And mass storage added another twist, as USB mass storage is handled quite similar to SCSI mass storage, thus having them look like an SCSI interface would save many hours of programming and debugging by simply letting the SCSI mass storage driver do the work.

Then again, a physical-device can as well be represented in several ways, like as a 'raw' or 'cooked' and the later even in multiple ways. All of this can be done by either a stack of drivers, or a single driver offering multiple views. There isn't a best way, not even a standard one. Every Unix and every device on its own.

So what at first looks like an easy Tower of Hanoi game, quickly runs into nightmarish Jenga with uneven sized blocks.

*1 - Much the same way as printcap is a special case for printers.

*2 - Well, devicedrivers can be made for next to anything. This is about physical devices in the primary sense used with Unix.

*3 - Including hubs, though, they are usually handled transparent by the generic USB driver due their basic nature to USB enumeration.

Improve this answer
6
  • I admit to misunderstandings (see opening disclaimer), but to better focus the question, which layer lets a raw device, say /dev/rsd0 operate in block mode /dev/sd0 and finally let sensible interchange between device and eventual userland programes? Perhaps termcap is the wrong place to look?
    – MKhomo
    Dec 9, 2019 at 14:59
  • @MKhomo That's the device driver. And in most cases a stack of such, with a some generic SCSI driver at the bottom, one for mass storage above that, followed by drivers for file systems and file access and so on. It all depends on the way the Unix in question was designed. Instead of a stack it can as well be a single driver installing several devices - after all a device as seen from user land is just a way to access funtionality - wo one physical interface can be seenin many ways at the same time. Have some man: netbsd.gw.com/cgi-bin/man-cgi?intro+4+NetBSD-current :)
    – Raffzahn
    Dec 9, 2019 at 15:05
  • @MKhomo Don't take me wrong, but this area is way too large to be covered in a simple answer. Starting with the enormus flexibility of USB, covering almost anything, over the need to press this somehow into the grown and rather fix structures of Unix and not ending with varying application requirements. Covering this would need a whole course in system design.
    – Raffzahn
    Dec 9, 2019 at 15:17
  • 1
    Thanks for eye-opening comments. One hopes the structure(s) of varying unices are not so ossified as to not admit new ways of interconnecting. Perhaps mine is the naive observation of outsider looking in, to think there is a recurring pattern starting from serial with 'line discipline' to parallel master-slave bus, and eventually to SCSI-like interconnects with minimal peer blocking, and now the versatile and extensible USB enumeration device hubs. One would hope that kernel thought leaders can come up with a generic device inter-connect architecture to solve plug and play issues among others.
    – MKhomo
    Dec 9, 2019 at 16:19
  • @MKhomo 'Ossified' - I like that wording. At least for Linux the situation did improve a lot with 2.2 (?) when the modular driver was introduced. It allows to partition handling according to controller, device and function as well as reuse of common elements. Then again, it's still a special to type configuration. I agree, USB is explicite made to support adaptable drivers and usage, which is great, but it's the little 'buts' every concrete device adds that makes a generic solution hard to archive. As a result, UIs get to carry the burden (and bloat) to handle it.
    – Raffzahn
    Dec 10, 2019 at 0:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .