linux-kernel - Re: [PATCH 00/21] ARCNET: Defibrillation

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]

Message-ID: <20150427145715.GC23151@pengutronix.de>
Date:	Mon, 27 Apr 2015 16:57:15 +0200
From:	Michael Grzeschik <mgr@...gutronix.de>
To:	David Miller <davem@...emloft.net>
Cc:	mkl@...gutronix.de, joe@...ches.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH 00/21] ARCNET: Defibrillation

Hi!

On Fri, Apr 24, 2015 at 11:58:53PM -0400, David Miller wrote:
> From: Marc Kleine-Budde <mkl@...gutronix.de>
> Date: Fri, 24 Apr 2015 23:14:41 +0200
> 
> > On 04/24/2015 08:47 PM, Joe Perches wrote:
> >> On Fri, 2015-04-24 at 19:20 +0200, Michael Grzeschik wrote:
> >>> Hi!
> >> 
> >> Hello.
> >> 
> >>> This patch series tries to reanimate the ARCNET hardware layer to be
> >>> somehow readable and maintainable again. It includes a lot of cleanup
> >>> patches. It also adds some fixes which leads the layer to become usable
> >>> again. And as a special treatment it adds more features like correct
> >>> loading and unloading of the com20020 card.
> >> 
> >> Wow.  Good for you, but why?  Does anyone still use these?
> > 
> > Yes, there are parts of the industry where "old" machines are
> > retrofitted with new hardware...and a lot of these machines still talk
> > ARCNET :)
> 
> But the real issue is, this layer is development wise in the same
> category as the IDE layer.
> 
> Any non-trivial change is nothing but pure risk, especially given the
> low level of test coverage the code gets.

Do you count coding style patches as non-trivial or trivial
patches?

> So I really only want to see the most critical obvious bug fixes
> submitted for this layer and drivers.

The cleanup changes I submitted should not change the actual behaviour.
Replacing the register access macros with their equivalent outb/inb
seems pretty obvious. What is your opinion on those?

I see that the "ARCNET: whitespace, tab and codingstyle fixes" patch is
pretty mixed up and not very reliable. But Joe has sent me a nice series
for the cleanup.

> And no I will not accept an argument stating that you have to
> restructure and clean this code up in order to fix the bugs.  That's
> bogus.

OK.

I have the following patches in this series which fix bugs found during
my development:

com20020-pci: add dev_port for udev handling
ARCNET: fix hard_header_len limit
ARCNET: com20020: add enable and disable device on open/close

I would send a new series containing only those patches with more
detailed patch descriptions, if that's fine with you?

Regards,
Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/