linux-kernel - Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms

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>] [day] [month] [year] [list]

Date:	Mon, 30 Jun 2008 13:59:53 +1000
From:	"John Williams" <john.williams@...alogix.com>
To:	"Stephen Neuendorffer" <stephen.neuendorffer@...inx.com>
Cc:	grant.likely@...retlab.ca, monstr@...nam.cz,
	linux-kernel@...r.kernel.org, arnd@...db.de,
	linux-arch@...r.kernel.org, "John Linn" <linnj@...inx.com>,
	matthew@....cx, will.newton@...il.com, drepper@...hat.com,
	microblaze-uclinux@...e.uq.edu.au, linuxppc-dev@...abs.org,
	vapier.adi@...il.com, alan@...rguk.ukuu.org.uk, hpa@...or.com,
	"Michal Simek" <monstr@...str.eu>
Subject: Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms

Hi Steve,

> In my opionion, we should only include dts files for reference designs, and
> it must be documented how to get the design that the dts corresponds to.

I'm not sure you (or Xilinx) are quite ready for the pain this implies
- have you tried browsing reference designs on Xilinx.com recently?
It's a total mishmash of tool versions, boards, you name it.  If
Xilinx is ready to declare a gold standard "ML401" design, and commit
to maintaining it tool version after tool version, lots of people will
be very happy, but I don't see it just yet!

I'm not having a go at you here, just questioning the notion that
there is really any such thing as a persistent 'reference design' for
these platforms.  These are not physical boards that get manufactured
and persist as real objects.

> MD5 hashing might be one way to prevent people from getting the dts file
> wrong, however without some way of checking it automatically, I don't think
> anyone will have the patience to checksum the design they have (even worse,
> with whitespace changes, the md5 sum will change, so this is pretty fragile.

Actually I was only joking about the md5 hashing - just to prove my point :)

> Having a device tree in the kernel for documentation *shouldn't* be
> necessary,

Well, yes and no.  A vanilla DTS that shows what a valid one might
look like - "oh, here's where I declare my main memory parameters,
..." has some value IMO.

> since noone should ever write their dts by hand. (right?)

I'm not certain you can guarantee that.

> Hence, I'd prefer to not put the dts file in the kernel at all, and but to
> automatically generate the dts and store it in the blockram of the design.
> This inextricably associates the dts with the design.

Whether the DTS lives in block ram or is pulled over the net by uboot
or whatever is not our call to make in the kernel - that's a
deployment issue.

> As for the copyright, I haven't been able to find much information on
> whether or not generated files are even copyrightable.  One might argue that
> they
> don't have sufficient 'creative value' to be copyrightable.  Or arguably,
> they are as copyrightable by the generator author as by the author or the
> .mhs file.

The DTS is a mechanical translation from one file format to another
(more or less).  Auto-inserting a copyright Xilinx (or anyone else) in
there would be unenforceable, and therefore should probably just go
away.

How would you feel if the FSF claimed copyright over object code
derived from your source files simply because you ran them through
gcc? :)  I believe there's a special clause in the GCC license to
explicitly cover this kind of situation.

Cheers,

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