linux-kernel - Re: [PATCH] ISDN: move card state init to separate function

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: <46531E58.6030506@garzik.org>
Date:	Tue, 22 May 2007 12:46:16 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	kkeil@...e.de
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	kai.germaschewski@....de, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ISDN: move card state init to separate function

Karsten Keil wrote:
> So what is the reason to do this now, does this block some changes in
> other places ? I did not change this code for long time because I know
> that this is a nightmare, the code was grown and grown (supporting more and
> more cards/chipsets) and is really nothing which should be used in future.
> So I would say it maybe better, if it doesn't block anything else, to
> replace HiSax completely with a new modular design. I know that here was not
> so much effort in the past years, but now I got some time to push mISDN
> forward and it looks not so bad to get the first parts ready for mainline
> in June.

ISDN is the biggest chunk of code blocking removal of some deprecated 
PCI interfaces.

If you want to replace the code completely with a newfangled modular 
design, I will gladly step out of the way and let that happen :)  I only 
know what I see right now, which is code that has sat around for a while 
not getting updated to the new PCI API.

Since I do not have any ISDN hardware, my plan was to do equivalent 
transformations of the code.  Each patch just shuffles code, but 
maintains a working state at all time, making it trivial to prove 
(mathematically, or with testing, or with git-bisect) that the code 
continues to work.

So, just tell me which you would prefer.  If you are going to fix all 
this stuff, there is plenty of other stuff on my list to work on. 
Otherwise I will create equivalent-transform patches that take the 
existing code and modify it just enough to be correct for the new PCI API.

	Jeff

-
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/