[PATCH 3/4] dev/io: Add a CRC-24Q implementation

[Gedare Bloom]

On Mon, Jan 22, 2024 at 11:13 AM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
> Hello Gedare,
>
> ----- Am 22. Jan 2024 um 17:49 schrieb Gedare Bloom gedare at rtems.org:
>
> > Similar to the other patch, this looks mostly useful.
> >
> > I think a lot of these kind of support code have been imported as
> > libraries through cpukit/libmisc.
> >
> > I'd be fine if we have our own versions, to define a cpukit/lib**
> >
> > But cpukit/dev has so far been for device-specific frameworks and I
> > would prefer keeping it that way.
>
> I already moved the base64 encoder from score to dev recently on Joels request. The base64 encoding/decoding and packet processing has something to do with input/output which is related to devices. So, the place is not completely wrong. Anyway I am happy to move it a third time, but then it would be great if you could suggest a concrete place and naming.
>
Yes, I understand the frustration and I recall this discussion.
Getting it out of score was definitely the right thing to do, and I'm
not actually asking that the existing _IO_* be moved out of /dev. My
opinion here is that cpukit/dev should be about device drivers or
devices to align with the relatively well understood notions of /dev.
The existing iobase64.c and io(v)printf.c code is directly supporting
device IO interfaces and I have no problem with them being there.
There is a relationship between the device and the IO function via the
IO_Put_char handle.

My confusion is the new code provided in the interface for base64
decoding and crc seems to be quite generic with no direct relationship
to a read/write of a device. The way it is written makes sense, and so
is the way it looks used by the packet processor service (based on a
quick skim). That however does raise the question why does the
existing base64 encoder print directly to the device, rather than
returning a character to be used by the caller. These kind of string
manipulation routines have in the past been found in libmisc. that is
also where the regulator landed. That would be my recommendation where
to put the packet processor and its support code.

I would like to see a cleaner separation between device-specific
code/frameworks, and more generic code.

Oddly, patch 4/4 didn't land in my inbox, but I see it in the
archives. Hopefully we have a proper patch management and review
process soon.

Gedare