On 13/03/2020 20:16, dufa...@hda.com wrote:
On Mar 13, 2020, at 08:42 , Sebastian Huber
<sebastian.hu...@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.
[...]
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
