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 09:11:55 +0200 (CEST)
From:	Michal Simek <Monstr@...nam.cz>
To:	microblaze-uclinux@...e.uq.edu.au
Cc:	John Williams <john.williams@...alogix.com>,
	grant.likely@...retlab.ca, 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, 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, John a others,

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

What is reference design? Is reference design design from BSB or from Xilinx page?
I don't want to add dts files to kernel which has relation with reference design. I added platform folder
with generic one for preparing for others distribution which can add their supported board. I don't want 
to added useless files to kernel. For non FPGA board make sense to me, they can't change everything.

I see the way that I can add ref design to my pages with correspond DTS file with some MD5 sums 
but I haven't seen to add for every reference board dts file. This is not way. I see that people will write to us
that they use board ml401 and they set ml401 in menuconfig but the kernel doesn't work. IMHO, if no board specific options
are not there, people will be looking for what is the next step. And If they want to use platform option which is there, they can add their own platform to his kernel. 

>Having a device tree in the kernel for documentation *shouldn't* be necessary,
>since noone should ever write their dts by hand. (right?)
>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.

This should be one choice to add DTB to bram with design but this could be only one choice
not in general. I can't imagine for example board where is reset logic on own IP which has specific 
reason. Developers will be overwrite their DTS a lot. 
I think this is the right time to stop discussion in this thread and annoying others with FPGA specific discuss. We can continue in specific thread.

>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.
>I admit in this case, I've followed the safe route by claiming a copyright,
>which at least at Xilinx has significant precedent.

This part can be discuss only on microblaze mailing list and has no relation with first pull to mainline kernel.
As I wrote in previous email copyright on generic DTS will not be there.

Michal

>Steve

-----Original Message-----
From: John Williams [mailto:john.williams@...alogix.com]
Sent: Sun 6/29/2008 5:02 PM
To: grant.likely@...retlab.ca
Cc: monstr@...nam.cz; linux-kernel@...r.kernel.org; arnd@...db.de;
linux-arch@...r.kernel.org; Stephen Neuendorffer; John Linn; 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
Subject: Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
 
On Sat, Jun 28, 2008 at 3:49 PM, Grant Likely <grant.likely@...retlab.ca>
wrote:
> On Thu, Jun 26, 2008 at 5:29 AM,  <monstr@...nam.cz> wrote:
>> From: Michal Simek <monstr@...str.eu>

>>  arch/microblaze/platform/generic/system.dts |  300
+++++++++++++++++++++++++++

> Since this is a generated file, and entirely bitstream specific, does
> it make sense to include it in the kernel tree?  If it does, then is
> it produced from one of the Xilinx reference designs?  Can you add
> documentation to the header that specifies exactly which design
> version this .dts is for?

I think there's value in having a generic DTS as an example or
template, even if it doesn't correspond to any specific machine.
Agreed a comment block explaining this is valuable.

I'd almost oppose any attempt to include a standard DTS for things
like ML401 boards etc - they are just misleading.  Unless we do MD5
hashes on MHS files, and use them as the filenames, any attempt to
define a standard platform will just fail and confuse people.  Better
to show them how to generate the DTS for their system.

>> +/*
>> + * (C) Copyright 2007-2008 Xilinx, Inc.
>> + * (C) Copyright 2007-2008 Michal Simek
>> + *
>> + * Michal SIMEK <monstr@...str.eu>
>
> If this is a generated file, then is this copyright notice even appropriate?

I agree.  I think Michal is just copying Xilinx's habit of putting
copyright headers in generated files, and it's one that we should stop
now.

Regards,

John




This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ