All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: linux-ia64@vger.kernel.org
Subject: Re: Unix code in Linux
Date: Sat, 21 Jun 2003 08:29:13 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105618417318726@msgid-missing> (raw)

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.



             reply	other threads:[~2003-06-21  8:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-21  8:29 Manfred Spraul [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-06-20 13:30 Unix code in Linux Manfred Spraul
2003-06-21  8:29 ` Manfred Spraul
2003-06-19 22:43 Neil Moore
2003-06-19 23:13 ` Miquel van Smoorenburg
2003-06-20  1:13   ` Neil Moore
2003-06-20 12:27 ` Jesse Pollard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-ia64-105618417318726@msgid-missing \
    --to=manfred@colorfullife.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.