[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ca9fc28e-f68a-4b80-b21f-08a3edf3903a@lunn.ch>
Date: Sat, 28 Oct 2023 00:55:31 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org,
rust-for-linux@...r.kernel.org, tmgross@...ch.edu,
benno.lossin@...ton.me, wedsonaf@...il.com
Subject: Re: [PATCH net-next v7 0/5] Rust abstractions for network PHY drivers
> For instance, as a trivial example, Andrew raised the maximum length
> of a line in one of the last messages. We would like to avoid this
> kind of difference between parts of the kernel -- it is the only
> chance we will get, and there is really no reason to be inconsistent
> (ideally, even automated, where possible).
It should be noted that netdev prefers 80, which the coding standard
expresses as the preferred value. checkpatch however now allows up to
100. The netdev CI job adds an extra parameter to checkpatch to
enforce the preferred 80.
You will probably find different levels of acceptance of 80 to 100 in
different subsystems. So i'm not sure you will be able to achieve
consistence.
It should also be noted that 80, or 100, is not a strict limit. Being
able to grep the kernel for strings is important. So the coding
standard allows you to go passed this limit in order that you don't
need to break a string. checkpatch understands this. I don't know if
your automated tools support such exceptions.
Andrew
Powered by blists - more mailing lists