Issues when adding a multi-port PCI serial card

[Sebastian Huber]

On 13/03/2020 20:16, dufault at hda.com wrote:

>
>> On Mar 13, 2020, at 08:42 , Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
> Thanks for replying.
>
>> On 12/03/2020 21:44, Peter Dufault wrote:
>>
>>> I've added an 8-port RS232 PCI Mezzanine Card to the "beatnik" BSP.  The console (aka serial port) code is confusing.
>>>
>>> I decided I should use what is in "bsp/console-termios.h"  as opposed to the "legacy console" approach, *even though* "legacy console" is used in many recent BSPS.
>> What is a recent BSP for you? I would call all BSPs which still use this major/minor number drivers a legacy BSP.
> The fact that all recent drivers have major and minor numbers of 0 is confusing.  I wanted a minor number in order to enumerate the serial ports.  I don't mind that RTEMS goes away from major and minor numbers, but doing an "ls -l" and seeing all those "0" entries is, as I said, confusing.
>
> * Does that happen on FreeBSD?

This looks like a bug. I never paid attention to the major/minor numbers.

>
>>> That approach went well, I created a replacement shared PowerPC console in "bsps/powerpc/shared/console/console-config.c" with only 129 lines of code and half of it comments.
>> This is probably all right. What we don't have in RTEMS is a generic device enumeration framework.
> Are you indirectly replying to my previous comment about wanting a minor number for serial device enumeration reasons?

Yes, you can modify the generic driver if you need a unit number. It 
could also generate the device file path.

For anything with a plug and play hardware (e.g. PCI) I would use the 
libbsd for device drivers. It already has everything you need for driver 
and device management.

>
>>> Where does the driver go:  Next I had to add the PCI multi-port serial card driver.  I put it in "bsps/shared/dev/pci/mp_serial.c".  The other directory choice was "bsps/shared/dev/serial".  I didn't like either, the "dev/pci" is very associated with PCI discovery and the "dev/serial" is very associated with the generic low-level serial driver support, even thought it has the "legacy-console" cruft in it.
>>>
>>> * Where should it go?
>> The serial drivers which are not specific to a BSP should go to "bsps/shared/dev/serial" or even "cpukit/dev/serial".
> I put the driver in "bsps/shared/dev/serial", I decided that was better than "/dev/pci".  I don't know what goes in "cpukit" versus "bsps".
>
> * What distinguishes where a shared code should go? Should much of what is "bsps/shared" be in "cpukit" instead?
In "bsps/shared" you can use BSP-specific header files. In "cpukit" you 
cannot use them.
>
>>> Difficulty in assigning common TTY names: Since my new shared PowerPC "console-config.c" created "/dev/ttyS0" and "/dev/ttyS1" I wanted to name the new serial devices with a number that started at 2, i.e., "/dev/ttyS2".
>>>
>>> * Is there a way in the "console-termios" framework to know what the highest "minor number" for a serial port is?  I searched, gave up, and made it a configuration item.
>> No, we don't have a framework for unit number assignments. It is not that easy if you look at the FreeBSD code. Why don't use use driver specific names, e.g. "/dev/pci-serial-XXX"?
> I don't want that because I just don't want that, I want generic serial ports to have generic names such as "/dev/ttySX".
>   
> * Can you explain why "/dev/pci-serial-XXX" is a good option for the end-user?

Yes, if it is a PCI-specific driver it should have a PCI-specific path. 
If it is managed by a generic console driver, then "/dev/ttySX" is fine.

[...]