Files
kaniko/vendor/github.com/cilium/ebpf/doc.go
T
Joe Kimmel 906cc96b59 Upgrade docker (#2440)
* somehow now the only thing that doesnt work is devices.Device

Signed-off-by: Joe Kimmel <jkimmel@vmware.com>

* this gets rid of all the compiler errors in the vendored code

Signed-off-by: Joe Kimmel <jkimmel@vmware.com>

* fixed some things but a bunch of tests and maybe some compiler steps are still failing

Signed-off-by: Joe Kimmel <jkimmel@vmware.com>

* all the things i figured out how to fix so far

Signed-off-by: Joe Kimmel <jkimmel@vmware.com>

* guess i had to redo go mods after rebasing again

Signed-off-by: Joe Kimmel <jkimmel@vmware.com>

* update docker constants to be SHOUTY CASE now

Signed-off-by: Joe Kimmel <jkimmel@vmware.com>

* include DestPath in resolveEnv

Signed-off-by: Joe Kimmel <jkimmel@vmware.com>

* fix one mistake in Docker lib upgrade and some typos/deprecations in the file

Signed-off-by: Joe Kimmel <jkimmel@vmware.com>

* last changes (hopefully) to update to new docker libs

Signed-off-by: Joe Kimmel <jkimmel@vmware.com>

---------

Signed-off-by: Joe Kimmel <jkimmel@vmware.com>
2023-03-23 20:34:25 -04:00

26 lines
1.3 KiB
Go

// Package ebpf is a toolkit for working with eBPF programs.
//
// eBPF programs are small snippets of code which are executed directly
// in a VM in the Linux kernel, which makes them very fast and flexible.
// Many Linux subsystems now accept eBPF programs. This makes it possible
// to implement highly application specific logic inside the kernel,
// without having to modify the actual kernel itself.
//
// This package is designed for long-running processes which
// want to use eBPF to implement part of their application logic. It has no
// run-time dependencies outside of the library and the Linux kernel itself.
// eBPF code should be compiled ahead of time using clang, and shipped with
// your application as any other resource.
//
// Use the link subpackage to attach a loaded program to a hook in the kernel.
//
// Note that losing all references to Map and Program resources will cause
// their underlying file descriptors to be closed, potentially removing those
// objects from the kernel. Always retain a reference by e.g. deferring a
// Close() of a Collection or LoadAndAssign object until application exit.
//
// Special care needs to be taken when handling maps of type ProgramArray,
// as the kernel erases its contents when the last userspace or bpffs
// reference disappears, regardless of the map being in active use.
package ebpf