lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 28 Oct 2023 00:55:31 +0200
From: Andrew Lunn <>
To: Miguel Ojeda <>
Cc: Jakub Kicinski <>,
	FUJITA Tomonori <>,,,,,
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

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.


Powered by blists - more mailing lists