All of lore.kernel.org
 help / color / mirror / Atom feed
* Unix code in Linux
@ 2003-06-19 22:43 Neil Moore
  2003-06-19 23:13 ` Miquel van Smoorenburg
  2003-06-20 12:27 ` Jesse Pollard
  0 siblings, 2 replies; 7+ messages in thread
From: Neil Moore @ 2003-06-19 22:43 UTC (permalink / raw)
  To: linux-kernel


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/

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: Unix code in Linux
@ 2003-06-20 13:30 Manfred Spraul
  2003-06-21  8:29 ` Manfred Spraul
  0 siblings, 1 reply; 7+ messages in thread
From: Manfred Spraul @ 2003-06-20 13:30 UTC (permalink / raw)
  To: Neil Moore; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: Unix code in Linux
@ 2003-06-21  8:29 Manfred Spraul
  0 siblings, 0 replies; 7+ messages in thread
From: Manfred Spraul @ 2003-06-21  8:29 UTC (permalink / raw)
  To: linux-ia64

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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2003-06-21  8:29 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-19 22:43 Unix code in Linux Neil Moore
2003-06-19 23:13 ` Miquel van Smoorenburg
2003-06-20  1:13   ` Neil Moore
2003-06-20 12:27 ` Jesse Pollard
  -- strict thread matches above, loose matches on Subject: below --
2003-06-20 13:30 Manfred Spraul
2003-06-21  8:29 ` Manfred Spraul
2003-06-21  8:29 Manfred Spraul

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.