linux-kernel - Re: ARM promising platform, needs to learn from PC.

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: <CAPweEDwvTcFFrsWhjhaRgC+1YbwGthxQrd40mw9H6aLgXzJ1Jg@mail.gmail.com>
Date:	Fri, 19 Aug 2011 12:53:30 +0100
From:	Luke Kenneth Casson Leighton <luke.leighton@...il.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	torvalds@...ux-foundation.org
Subject: Re: ARM promising platform, needs to learn from PC.

> I'm suggesting splitting out the crazy part into a separate project
> that does this. Open-source. Like a mini-kernel.

 linus, i'm surprised, shocked even!  are you seriously proposing that
the linux kernel be split into two, ooo, i dunno... something along
the lines of a core and an OSKit v2.0?  the last time OSKit was
created it didn't go down too well :)  but seriously: yes, i also came
up with this idea, and, whilst it sounds like a great idea in
principle, it is merely "moving the problem".

 likewise with any other ideas such as allowing the linux kernel to be
a userspace application (running under L4KA or other microkernel).

 so i think you'll find that whilst such ideas are great in principle,
they merely solve _your_ stress levels, not anyone else's :)

> Because the thing is,
> the main kernel doesn't care, and _shouldn't_ care. Those board files
> are just noise.

 yes, and they're necessary.  they link everything together, for the
actual real-world manufacturer shipping the real-world customised
one-of-a-kind mass-volume product, of which there are merely many many
thousands if not millions of units sold.

 yes, it initially sounded like i was arguing "in favour" of those...
noisy-board-files, but you can see - if you read to the end of the
sentence - i'm most certainly not.

 this is where the "selfish patch is out, collaborative patches are
in" rule would come into play.

 under the proposed rule, such board files would *not* qualify.

 however, if that board file was for a device that was part of a
collaboration (such as: it was for the pandaboard, IMX53QSB, or its
hardware CAD/CAM files were available under an OSI-Approved License),
i would argue that it *should* qualify.

 i've listed examples of each, in the FAQ.

 it would be good to be able to clearly link each concrete example to
a real-world case where linux developers have clearly gone "argggh!",
to evaluate how effective the proposed "selfish is out, collaboration
is in" rule would be.

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