2010-05-29 07:09:12 +04:00
|
|
|
#
|
|
|
|
|
# Makefile for the Linux/TILE kernel.
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
extra-y := vmlinux.lds head_$(BITS).o
|
|
|
|
|
obj-y := backtrace.o entry.o init_task.o irq.o messaging.o \
|
|
|
|
|
pci-dma.o proc.o process.o ptrace.o reboot.o \
|
arch/tile: more /proc and /sys file support
This change introduces a few of the less controversial /proc and
/proc/sys interfaces for tile, along with sysfs attributes for
various things that were originally proposed as /proc/tile files.
It also adjusts the "hardwall" proc API.
Arnd Bergmann reviewed the initial arch/tile submission, which
included a complete set of all the /proc/tile and /proc/sys/tile
knobs that we had added in a somewhat ad hoc way during initial
development, and provided feedback on where most of them should go.
One knob turned out to be similar enough to the existing
/proc/sys/debug/exception-trace that it was re-implemented to use
that model instead.
Another knob was /proc/tile/grid, which reported the "grid" dimensions
of a tile chip (e.g. 8x8 processors = 64-core chip). Arnd suggested
looking at sysfs for that, so this change moves that information
to a pair of sysfs attributes (chip_width and chip_height) in the
/sys/devices/system/cpu directory. We also put the "chip_serial"
and "chip_revision" information from our old /proc/tile/board file
as attributes in /sys/devices/system/cpu.
Other information collected via hypervisor APIs is now placed in
/sys/hypervisor. We create a /sys/hypervisor/type file (holding the
constant string "tilera") to be parallel with the Xen use of
/sys/hypervisor/type holding "xen". We create three top-level files,
"version" (the hypervisor's own version), "config_version" (the
version of the configuration file), and "hvconfig" (the contents of
the configuration file). The remaining information from our old
/proc/tile/board and /proc/tile/switch files becomes an attribute
group appearing under /sys/hypervisor/board/.
Finally, after some feedback from Arnd Bergmann for the previous
version of this patch, the /proc/tile/hardwall file is split up into
two conceptual parts. First, a directory /proc/tile/hardwall/ which
contains one file per active hardwall, each file named after the
hardwall's ID and holding a cpulist that says which cpus are enclosed by
the hardwall. Second, a /proc/PID file "hardwall" that is either
empty (for non-hardwall-using processes) or contains the hardwall ID.
Finally, this change pushes the /proc/sys/tile/unaligned_fixup/
directory, with knobs controlling the kernel code for handling the
fixup of unaligned exceptions.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
2011-05-26 20:40:09 +04:00
|
|
|
setup.o signal.o single_step.o stack.o sys.o sysfs.o time.o traps.o \
|
2010-05-29 07:09:12 +04:00
|
|
|
intvec_$(BITS).o regs_$(BITS).o tile-desc_$(BITS).o
|
|
|
|
|
|
arch/tile: Add driver to enable access to the user dynamic network.
This network (the "UDN") connects all the cpus on the chip in a
wormhole-routed dynamic network. Subrectangles of the chip can
be allocated by a "create" ioctl on /dev/hardwall, and then to access the
UDN in that rectangle, tasks must perform an "activate" ioctl on that
same file object after affinitizing themselves to a single cpu in
the region. Sending a wormhole-routed message that tries to leave
that subrectangle causes all activated tasks to receive a SIGILL
(just as they would if they tried to access the UDN without first
activating themselves to a hardwall rectangle).
The original submission of this code to LKML had the driver
instantiated under /proc/tile/hardwall. Now we just use a character
device for this, conventionally /dev/hardwall. Some futures planning
for the TILE-Gx chip suggests that we may want to have other types of
devices that share the general model of "bind a task to a cpu, then
'activate' a file descriptor on a pseudo-device that gives access to
some hardware resource". As such, we are using a device rather
than, for example, a syscall, to set up and activate this code.
As part of this change, the compat_ptr() declaration was fixed and used
to pass the compat_ioctl argument to the normal ioctl. So far we limit
compat code to 2GB, so the difference between zero-extend and sign-extend
(the latter being correct, eventually) had been overlooked.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
2010-06-26 01:00:56 +04:00
|
|
|
obj-$(CONFIG_HARDWALL) += hardwall.o
|
2010-05-29 07:09:12 +04:00
|
|
|
obj-$(CONFIG_TILEGX) += futex_64.o
|
|
|
|
|
obj-$(CONFIG_COMPAT) += compat.o compat_signal.o
|
|
|
|
|
obj-$(CONFIG_SMP) += smpboot.o smp.o tlb.o
|
|
|
|
|
obj-$(CONFIG_MODULES) += module.o
|
|
|
|
|
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
|
|
|
|
|
obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o
|
2010-11-02 19:05:10 +03:00
|
|
|
obj-$(CONFIG_PCI) += pci.o
|