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
Ok.
> - 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 ?
Sure.
--
Regards,
Mariusz Kozlowski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
