On Mon, 9 May 2022, Helge Deller wrote:
> Hello Ilpo,
>
> On 5/9/22 11:34, Ilpo Järvinen wrote:
> > Some defines are the same across all archs. Move the most obvious
> > intersection to termbits-common.h.
>
> I like your cleanup patches, but in this specific one, does it makes sense
> to split up together-belonging constants, e.g.
>
> > diff --git a/arch/parisc/include/uapi/asm/termbits.h b/arch/parisc/include/uapi/asm/termbits.h
> > index 6017ee08f099..7f74a822b7ea 100644
> > --- a/arch/parisc/include/uapi/asm/termbits.h
> > +++ b/arch/parisc/include/uapi/asm/termbits.h
> > @@ -61,31 +61,15 @@ struct ktermios {
> >
> >
> > /* c_iflag bits */
> > -#define IGNBRK 0x00001
> > -#define BRKINT 0x00002
> > -#define IGNPAR 0x00004
> > -#define PARMRK 0x00008
> > -#define INPCK 0x00010
> > -#define ISTRIP 0x00020
> > -#define INLCR 0x00040
> > -#define IGNCR 0x00080
> > -#define ICRNL 0x00100
> > #define IUCLC 0x00200
> > #define IXON 0x00400
> > -#define IXANY 0x00800
> > #define IXOFF 0x01000
> > #define IMAXBEL 0x04000
> > #define IUTF8 0x08000
>
> In the hunk above you leave IUCLC, IXON, IXOFF... because they seem unique to parisc.
> The other defines are then taken from generic header.
> Although this is correct, it leaves single values alone, which make it hard to verify
> because you don't see the full list of values in one place.
While I too am fine either way, I don't think these are as strongly
grouped as you seem to imply. There's no big advantage in having as much
as possible within the same file. If somebody is looking for the meaning
of these, these headers are no match when compared e.g. with stty manpage.
For c_iflag, the break, parity and cr related "groups" within c_iflag are
moving completely to common header.
IXANY is probably only one close to borderline whether it kind of belongs
to the same group as IXON/IXOFF (which both by chance both remained on the
same side in the split). I don't think it does strongly enough to warrant
keeping them next to each other but I'm open what opinions others have on
it.
The rest in c_iflag don't seem to be strongly tied/grouped to the other
defines within c_iflag. They're just bits that appear next/close to each
other but are not tied by any significant meaning-based connection.
C_oflag is more messy. I exercised grouping based judgement with c_oflag
where only the defines with all bits as zero would have moved to the
common header breaking the groups very badly. That is, only CR0 would have
moved and CR1-3 remained in arch headers, etc. which made no sense to do.
One could argue, that since ONLCR (and perhaps CRDLY) are not moving, no
other cr related defines should move either.
> > @@ -112,24 +96,6 @@ struct ktermios {
> >
> > /* c_cflag bit meaning */
> > #define CBAUD 0x0000100f
> > -#define B0 0x00000000 /* hang up */
> > -#define B50 0x00000001
> > -#define B75 0x00000002
> > -#define B110 0x00000003
> > -#define B134 0x00000004
> > -#define B150 0x00000005
> > -#define B200 0x00000006
> > -#define B300 0x00000007
> > -#define B600 0x00000008
> > -#define B1200 0x00000009
> > -#define B1800 0x0000000a
> > -#define B2400 0x0000000b
> > -#define B4800 0x0000000c
> > -#define B9600 0x0000000d
> > -#define B19200 0x0000000e
> > -#define B38400 0x0000000f
> > -#define EXTA B19200
> > -#define EXTB B38400
>
> Here all baud values are dropped and will be taken from generic header,
> which is good.
>
> That said, I think it's good to move away the second hunk,
> but maybe we should keep the first as is?
>
> It's just a thought. Either way, I'm fine your patch if that's the
> way which is decided to go for all platforms.
Yes, lets wait and see what the others think.
Thanks for taking a look!
--
i.
