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:	Wed, 1 Sep 2010 14:51:17 -0500
From:	david.hagood@...il.com
To:	linux-kernel@...r.kernel.org
Subject: How to allocate a region of address space (NOT RAM!)

I'm working with a single chip system (specifically, a PPC core) that has
onboard devices. I need to allocate a region of address space that is
unused, so that I can configure one of the on-chip devices to occupy that
space. The region of address space allocated must NOT have anything there
already - no RAM, no devices.

As far as I can see, there is no "bus" object I can talk to in order to
allocate address space, as one would do when allocating space on PCI. How
do I grab a region of address space, and be sure that nobody else is going
to frob it?

I could just look at the memory map, plunk my flag down and say "I claim
this address in the name of Endpoint!" but that doesn't keep me from
accidentally laying claim to New York, nor does it stop somebody else from
sailing in behind me and plunking their flag down.

Is there some master resource somewhere in the kernel that tracks the
allocation of physical address space, in the same way that kalloc tracks
the allocation of RAM space? Is there some API I've missed that will
allocate space and make sure it gets mapped into virtual space for me, or
will I have to roll my own solution?


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