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  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:	Sat, 2 Dec 2006 12:00:24 +0100
From:	Mariusz Kozlowski <>
To:	Willy Tarreau <>
Subject: Re: [2.4 PATCH] missing parenthesis

Hi Willy, 

> Thanks for your work at fixing all this code. I'm wondering though,
> given the type of errors, this code should never have been able to
> build at all, so that means that it might not be used at all.

Either not used or #ifdef'ed so much that it is rarely build.

> As a general rule of thumb, keep in mind that we're not much tempted
> to fix known unused code, especially if it's unmaintained. The reason

Maybe dumb question but ... how do I know which parts of code are unused
and/or unmaintained?

> is simple : when some code does not work, people who need it often
> maintain patches in their tree to make it work. When we start changing
> things there, their patches often apply with rejects. Anyway, *I* am
> still for a clean kernel because I know that there's nothing more
> annoying than spending days chasing a bug which we discover was known
> for years.
> So what I can propose you is that we :
>   - postpone those patches for 2.4.35-pre


>   - ask maintainers of each of these files if he accepts to fix the
>     file, because some of them are totally against any such change.

Ok. Couple of questions:

- how do we do that?
- do I resend each patch to proper maintainer?
- if there is no maintainer then what? (btw. is there any other
more accurate source of MAINTAINERS for each file in the kernel tree?)
- do I have to resend them once more to LKML?

>   - we would merge the accepted patches and those without any reply
>     which we consider relevant early in the 35-pre cycle so that
>     people have some time to inform us about the potential conflicts
>     they encounter.
> Quite frankly, there should be very few problems, considering that we
> have affected more files with the gcc4 patches and that nobody
> complained.
> As an exception, if you get some maintainer's approval for some of
> the patches during 2.4.34 cycle, of course I will merge them first
> because as I said, it's important to maintain supported code in good
> shape.
> Is it OK for you ?



	Mariusz Kozlowski
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists