Unix code in Linux

Unix code in Linux

[Neil Moore]

Slashdotter lspd pointed this out in a recent thread, thereby
demonstrating that slashdot isn't completely useless.

Compare:
  /usr/src/linux/arch/ia64/sn/io/ate_utils.c in Linux
to:
  unix/malloc.c in UNIX 6th Edition (page 25 of the Lions code,
  lines 2522--2589)

atefree() is very obviously based on Unix's mfree(), and atealloc() on
malloc().  atefree()/mfree() even have the *same leading comment*.  Of
course, there are some changes, but the overall structure and many of
the details remain.

The copyright notice on ate_utils.c says:

 * This file is subject to the terms and conditions of the GNU General Public
 * License.  See the file "COPYING" in the main directory of this archive
 * for more details.
 *
 * Copyright (C) 1992 - 1997, 2000-2002 Silicon Graphics, Inc. All rights reserved.


This code is obviously not a trade secret, since it has been published
in the 1996 version of the Lions book.  However, it is copyrighted,
and the book's (C) notice says:
  . . . SCO [i.e. the Santa Cruz Operation, not The SCO Group] has
  granted a license to publish solely for the purpose of creating an
  educational work.  SCO grants no license for any other use of this
  material . . . .


What kind of license did SGI have to the Unix code ca. 2000--2002?
Did the original malloc()/mfree() appear in BSD Lite (and thus lost to
USL/Novell in the settlement)?  Is there any reason to replace this
code?  Is there any reason not to replace this code?

-- 
Neil Moore: neil@s-z.org, http://s-z.org/~neil/

Re: Unix code in Linux

[Miquel van Smoorenburg]

In article <E19T87m-000367-SF@dirac.s-z.org>,
Neil Moore  <neil@s-z.org> wrote:
>
>Slashdotter lspd pointed this out in a recent thread, thereby
>demonstrating that slashdot isn't completely useless.
>
>Compare:
>  /usr/src/linux/arch/ia64/sn/io/ate_utils.c in Linux
>to:
>  unix/malloc.c in UNIX 6th Edition (page 25 of the Lions code,
>  lines 2522--2589)

BSD 4.3 and Unix V7 source is browsable online at
http://tamacom.com/unix/

Choose "V7" and search for "mfree".

The source being online is possible because the V1 - V7 source was
put under a BSD-like license by Caldera in 2002. A copy of the license
is still at ftp://minnie.tuhs.org/UnixArchive/Caldera-license.pdf

(there's much more at ftp://minnie.tuhs.org/UnixArchive/, including
V6, V7 and 2.11BSD source).

So, in this particular case this doesn't seem to be a problem.

Mike.

Re: Unix code in Linux

[Neil Moore]

Miquel van Smoorenburg writes:
> The source being online is possible because the V1 - V7 source was
> put under a BSD-like license by Caldera in 2002. A copy of the license
> is still at ftp://minnie.tuhs.org/UnixArchive/Caldera-license.pdf
> 
> (there's much more at ftp://minnie.tuhs.org/UnixArchive/, including
> V6, V7 and 2.11BSD source).
> 
> So, in this particular case this doesn't seem to be a problem.

The license to which you referred says, in part:

Copyright(C) Caldera International Inc. 2001-2002. All rights
reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

[. . .] Redistributions of source code and documentation must retain the above
copyright notice, this list of conditions and the following
disclaimer. [. . .]


The file in question in the Kernel does not include any Caldera
copyright notice, and in fact claims that the copyright belongs to
SGI.  Isn't that a violation of Caldera's copyright?  

Of course, if SGI has an unlimited right to relicense Unix code as its
own, it's not an issue.

-- 
Neil Moore: neil@s-z.org, http://s-z.org/~neil/

Re: Unix code in Linux

[Jesse Pollard]

On Thursday 19 June 2003 17:43, Neil Moore wrote:
> Slashdotter lspd pointed this out in a recent thread, thereby
> demonstrating that slashdot isn't completely useless.
>
> Compare:
>   /usr/src/linux/arch/ia64/sn/io/ate_utils.c in Linux
> to:
>   unix/malloc.c in UNIX 6th Edition (page 25 of the Lions code,
>   lines 2522--2589)
>
> atefree() is very obviously based on Unix's mfree(), and atealloc() on
> malloc().  atefree()/mfree() even have the *same leading comment*.  Of
> course, there are some changes, but the overall structure and many of
> the details remain.
>
> The copyright notice on ate_utils.c says:
>
>  * This file is subject to the terms and conditions of the GNU General
> Public * License.  See the file "COPYING" in the main directory of this
> archive * for more details.
>  *
>  * Copyright (C) 1992 - 1997, 2000-2002 Silicon Graphics, Inc. All rights
> reserved.
>
>
> This code is obviously not a trade secret, since it has been published
> in the 1996 version of the Lions book.  However, it is copyrighted,
> and the book's (C) notice says:
>   . . . SCO [i.e. the Santa Cruz Operation, not The SCO Group] has
>   granted a license to publish solely for the purpose of creating an
>   educational work.  SCO grants no license for any other use of this
>   material . . . .

I believe the original malloc/free code came from the "C programming language"
way back around 1975-79".

Almost all of the base allocators came out of that book. And it was listed
only as "a memory allocator", and the algorithms go back even farther. (I was
taught that one using a fortran array around 1973.. and was told then that
it had been used by IBM/CDC/... for memory allocation in assembler...)

Really.. there are only so many different ways to allocate memory, and this is
one of the most basic. Lisp interpreters always had the most elaborate and
complete ones, including this one. It is only slightly more complex than the
old stack "mark/release" allocator in Pascal.

Re: Unix code in Linux

[Manfred Spraul]

Neil wrote:

>Is there any reason to replace this
>code? 
>
Yes, it's ugly as hell.
As far as I can see, the only user of ate_malloc are a few rmalloc 
calls. There is one rmalloc_align call, but afaics the function is not 
implemented.

The code is filled with #defines that rename linux functions - 
mutex_spinlock, spin_lock_destroy(), whatever.
There is so much renaming that they even create a prototype for a #define:

> arch/ia64/sn/io/sn1/pcibr.c
> L40: #define rmalloc atealloc
> L331: extern uint64_t rmalloc(struct map *mp, size_t size);

(it seems sn1 got killed recently, I searched in lxr.linux.no)

AFAICS ate_malloc should die, and the rmalloc callers should use 
request_resource & friends from <linux/ioport.h>.

--
    Manfred

Re: Unix code in Linux

[Manfred Spraul]

atealloc is even worse than I noticed immediately:

* it allocates a semaphore, just in case. Never used.
* it allocates a spinlock and stores the pointer to the spinlock
  in .m_size of the 2nd map entry.
* then defines and one-line wrapper functions to obfuscate
  what's going on:
	pcibr_ate_alloc is a wrapper around rmalloc.
	rmalloc is a #define to atealloc
	atealloc is the map allocator.
* it seems the author never heared of include files - the 
  function prototypes are scattered around in the .c files,
  instead of including <asm/sn/ate_utils.h>

The actual users are in arch/ia64/sn/io/sn2/

There are 2 users:
*********
win_map: It seems to be used for locating io port and memory ranges for pci device initialization.

* creation: in pciio.c:
  - new maps are allocated with pciio_device_win_map_new().
    They are initially empty.
  - The maps are filled with pciio_device_win_populated().
  - they are destroyed with pciio_device_win_map_free().
* use:
  - allocation with pciio_device_win_alloc().
  - free with pciio_device_win_free().

Users are in pcibr/pcibr_{slot,dvr}.c: pcibr_bus_addr_alloc and pcibr_bus_addr_free.

*********
bs_ext_ate_map and bs_int_ate_map: management of address translation entries (ATE).

* creation: created inside pcibr_attach2, destroyed in pcrbr_detach.
	pcibr/pcibr_dvr.c
* use: in pcibr/pcibr_ate.c
	pcibr_ate_alloc, pcibr_ate_free.

The real user is pcibr_dmamap_alloc.
*********

What about deleting ate_utils.c and adding a rmalloc implementation (textbook or bsd) to linux/lib?
Any volunteers?
--
	Manfred
P.S.: I'd propose that the GPL rule that a change must be tagged with the name of the person who changes (or adds) a file is enforced - atealloc.c is only tagged with "SGI", thus I don't know who should be shot for writing that.