sv_addr.agh non-free?

[Hans-Peter Nilsson]

> From: Alexandre Oliva <lxoliva at fsfla.org>
> Date: Tue, 08 Dec 2009 21:28:54 -0200

Hi Alexandre!

> On Dec  7, 2009, Sam Geeraerts <samgee at elmundolibre.be> wrote:
> 
> > The gNewSense dev team have been reviewing some bug reports recently, 
> > and submitting them upstream. There's a bug report of a file in Linux 
> > (sv_addr.agh). It looks like a C header file and the comment says it was 
> > generated from another file. Because the original file is not in Linux' 
> > source we suspect this to be a GPL violation [1], so we removed it.
> 
> > As far as I can see linux-libre doesn't remove the file. If so, can you 
> > explain why that is the case?
> 
> > [1] http://bugs.gnewsense.org/Bugs/00323
> 
> Let's say I'd consider it believable if someone told me modifying that
> .agh header file would be just as convenient as modifying the .rd file,
> and the reason for the comment was solely to avoid divergence during
> development of the hardware or somesuch.

Exactly.  The .rd-file in question defines the addresses and
fields of I/O ports and is used to generate both the C header
file as well as information in the hardware description language
of choice.  If I now had the need, say, to fix some preprocessor
issue in that file, I'd probably *not* try and find that
original .rd-file and regenerate, but just edit the .agh-file.

> If this is so, it would be one of multiple most convenient forms for
> making changes to the program, and thus qualify as source code.
> 
> 
> That said, it might be more desirable to have the original file and
> whatever programs are needed to modify it and extract the information
> from it.
> 
> Maybe Hans Peter Nilsson (Cc:ed), my GCC and binutils colleague, could
> shed some light on this issue?  Hans, you think there's any chance Axis
> could contribute to Linux the files and programs mentioned in that
> headed file?  Namely:
> 
> /*
> * This file was automatically generated by /n/asic/bin/reg_macro_gen
> * from the file `/n/asic/projects/etrax_ng/doc/work/etrax_ng_regs.rd'.
> * Editing within this file is thus not recommended,
> * make the changes in `/n/asic/projects/etrax_ng/doc/work/etrax_ng_regs.rd' instead.
> */

I'll ask internally, but as you might guess there's little
practical point -- you can't change the silicon anyway.

It seems likely to me, that there's already precedent on
hardware description headers that are generated as part of the
silicon development process.  Is there some URL I can pass along?

brgds, H-P