linux-kernel - Re: [PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the number of xilinx ps uarts

lists.openwall.net		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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 May 2017 14:31:08 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Michal Simek <michal.simek@...inx.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Sam Povilus <kernel.development@...il.us>,
        <gregkh@...uxfoundation.org>, <jslaby@...e.com>,
        <soren.brinkmann@...inx.com>, <linux-serial@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the
 number of xilinx ps uarts

> I am not saying that config option is perfect solution. It is at least
> aligned with 5 others serial drivers in the tree.

And the fact people keep doing hacks jutifies continuing to make a mess.
Especialy as in this case it's entirely theoretical. Nobody has produced
actual hardware that hits the limit. Nobody has filed a bug, nobody is
impacted.

Creating extra CONFIG_ entries for junk like this is ridiculous, most of
the others at least have the excuse of being old code.

Generally it is better to call uart_register_driver from the probe method
because that way you don't waste time and memory registering drivers for
stuff that isn't even present however if you have no idea how many
devices there might be then you still really need to pass a suitable limit
and handle it internally dynamically allocating as needed.

If someone was hitting this in the real world and you posted a patch that
just changed the constant to 8 or 16 or whatever was needed I wouldn't
care too much, but adding CONFIG_ entries just makes stuff harder and
harder to config and more and more impossible to keep generic.

I keep hearing that the ARM folks are trying to get one unified kernel.
CONFIG_ options is not how to do that.

Alan