[an error occurred while processing this directive]

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

[an error occurred while processing this directive]

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

Message-ID: <6784529b0901040822q1a64e2dfi64f0da781f2a8223@mail.gmail.com>
Date:	Sun, 4 Jan 2009 19:22:18 +0300
From:	"Vladimir Dronnikov" <dronnikov@...il.com>
To:	"Paul Mundt" <lethal@...ux-sh.org>,
	"Rob Landley" <rob@...dley.net>, "H. Peter Anvin" <hpa@...or.com>,
	"Leon Woestenberg" <leon.woestenberg@...il.com>,
	"Embedded Linux mailing list" <linux-embedded@...r.kernel.org>,
	linux-kernel@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Sam Ravnborg" <sam@...nborg.org>
Subject: Re: PATCH [0/3]: Simplify the kernel build by removing perl.

> Let's look at the rationale presented so far in this thread:
>
>        1 - Being able to build the kernel natively on a constrained
>        target is useful, regardless of whether it is being used for
>        regression/stress testing or for headers installation or whatever
>        else.
>
>        2 - Cross-compiling perl is hard.
>
>        3 - Some oddly constrained target distributions manage to ship
>        with an entire toolchain yet fail to provide any implementation
>        of perl.
>
>        4 - It wasn't required before.

OK, let's see.

> If you have enough space and CPU power and
> complete build environment to crunch away at the kernel for stress
> testing natively, you can do the same with building perl and negating
> point #2.

It seems you meant "If you have enough space ... for stress testing
natively, you _MUST ALSO_ do the same with building perl  _TO JUST_
negate point #2". From this point of view your further arguments are
obvious.

>
> #2 is another byproduct of your environment and generally a non-issue.
>

So you put a constraint on environment to build kernel. Not on a
specific version of shell or gcc. But require SANE environment in
rhetoric sence. In the absence of clear specification of sane
environment it _IS_ an issue. Or simply: "sane" now reads "perlful
enough"?

>
> If there is anything I missed, feel free to add it to the list.
>

The rationale of changes being proposed is to keep people able to make
their choice on how to build and use their environment. If the code,
which now has to be generated by perl scripts, was shipped with
linux*.tar.bz2, I'd nullify the majority of my objections. Please, DO
NOT require this code to be BUILT, and many would again be happy. You
see, the total question is then reduces to some changes in makefiles
(eliminating FORCE prerequisites).

Otherwise you just force the number of people to invent and maintain
"regress" patches, which is counter-progressive in all sences.

Best regards,
--
Vladimir V. Dronnikov
--
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/