ret = drm_of_component_probe(&pdev->dev, compare_of, &demo_drm_ops); if (ret) { pr_err("drm_of_component_probe failed\n"); } else { pr_err("drm_of_component_probe\n"); }
return0; }
// This function is called before the devm_ resources are released staticintdriver_remove(struct platform_device *pdev) { structdrm_device *drm = platform_get_drvdata(pdev);
// This function is called on kernel restart and shutdown staticvoiddriver_shutdown(struct platform_device *pdev) { drm_atomic_helper_shutdown(platform_get_drvdata(pdev)); }
Dump the contents of memory from start_addr to end_addr, or the value of expr, to filename in the given format.
The format parameter may be any one of:
binary
Raw binary form.
ihex
Intel hex format.
srec
Motorola S-record format.
tekhex
Tektronix Hex format.
verilog
Verilog Hex format.
将一个文件加载进内存
1
restore filename [binary] bias start end
Restore the contents of file filename into memory. The restore command can automatically recognize any known BFD file format, except for raw binary. To restore a raw binary file you must specify the optional keyword binary after the filename.
If bias is non-zero, its value will be added to the addresses contained in the file. Binary files always start at address zero, so they will be restored at address bias. Other bfd files have a built-in location; they will be restored at offset bias from that location.
If start and/or end are non-zero, then only data between file offset start and file offset end will be restored. These offsets are relative to the addresses in the file, before the bias argument is applied.
Under Windows, the * and + registers are equivalent.
For X11 systems, though, they differ. For X11 systems, * is the selection, and + is the cut buffer (like clipboard).
Text selected, or otherwise highlighted in one X11 app is available in the selection buffer.
Text explicitly copied or cut is available in the cut buffer.
Input completion is available. If you forgot the name of a function but recall only some characters of the head, please input them and press key.
1 2
:Gtags fu<TAB> :Gtags func <- Vim will append 'nc'.
To go to the referenced point of ‘func’, add -r option.
1
:Gtags -r func
To go to any symbols which are not defined in GTAGS, try this.
1
:Gtags -s func
To go to any string other than symbol, try this.
1
:Gtags -g ^[sg]et_
This command accomplishes the same function as grep(1) but is more convenient because it retrieves an entire directory structure.
To get list of objects in a file ‘main.c’, use -f command.
1
:Gtags -f main.c
If you are editing main.c itself, you can use ‘%’ instead.
1
:Gtags -f %
You can get a list of files whose path include specified pattern. For example:
1 2 3
:Gtags -P /vm/ <- all files under 'vm' directory. :Gtags -P \.h$ <- all include files. :Gtags -P init <- all paths includes 'init'
If you omitted an argument and input only key to the prompt, vim shows list of all files in the project.
Since all short options are sent to global(1) as is, you can use the -i, -o, -O, and so on.
For example, if you want to ignore case distinctions in pattern.
1
:Gtags -gi paTtern
It will match to both of ‘PATTERN’ and ‘pattern’.
If you want to search a pattern which starts with a hyphen like ‘-C’ then you can use the -e option like grep(1).
1
:Gtags -ge -C
By default, Gtags command search only in source files. If you want to search in both source files and text files, or only in text files then
1 2
:Gtags -go pattern # both source and text :Gtags -gO pattern # only text file
gtags-cscope
1 2 3 4 5 6 7 8 9
Find symbol :cs find 0 or s Find definition :cs find 1 or g Find functions called by this function :cs find 2 or d Find reference :cs find 3 or c Find text string :cs find 4 or t Find egrep pattern :cs find 6 or e Find path :cs find 7 or f Find include file :cs find 8 or i Find assignments :cs find 9 or a
Tig is an ncurses-based text-mode interface for git(1). It functions mainly as a Git repository browser, but can also assist in staging changes for commit at chunk level and act as a pager for output from various Git commands.
Command line options recognized by Tig include all valid git-log(1) and git-diff(1) options, as well as the following subcommands and Tig-specific options. The first command line parameter not starting with "-" is interpreted as being either a revision specification or a path and will end the option parsing. All additional options will be passed to the underlying Git command.
show Open diff view using the given git-show(1) options.
blame Show given file annotated by commits. Takes zero or more git-blame(1) options. Optionally limited from given revision.
status Start up in status view.
log Start up in log view, displaying git-log(1) output.
reflog Start up in reflog view.
refs Start up in refs view.
stash Start up in stash view.
grep Open the grep view. Supports the same options as git-grep(1).
+<number> Show the first view with line <number> visible and selected.
-v, --version Show version and exit.
-h, --help Show help message and exit.
-C<path> Run as if Tig was started in <path> instead of the current working directory.
Tig enters pager mode when input is provided via stdin and supports the following subcommands and options:
· When the show subcommand is specified and the --stdin option is given, stdin is assumed to be a list of commit IDs and will be forwarded to the diff view’s underlying git-show(1) command. For example:
$ git rev-list --author=vivien HEAD | tig show --stdin
· When --stdin is given, stdin is assumed to be a list of commit IDs and will be forwarded to the main view’s underlying git-log(1) command. For example:
$ tig --no-walk --stdin < cherry-picks.txt
· When --pretty=raw is given, stdin is assumed to be a "pretty=raw" formatted output similar to that of git-log(1). For example:
$ git reflog --pretty=raw | tig --pretty=raw
When no subcommands nor options are given, the pager view will be used for displaying the Git command input given on stdin. The pager view assumes the input is either from git-log(1) or git-diff(1) and will highlight it similar to the log and diff views. For example:
In addition to environment variables used by Git (e.g. GIT_DIR), Tig defines the ones below. The command related environment variables have access to the internal state of Tig via replacement variables, such as %(commit) and %(blob). See tigrc(5) for a full list.
TIGRC_USER Path of the user configuration file (defaults to ~/.tigrc or $XDG_CONFIG_HOME/tig/config).
TIGRC_SYSTEM Path of the system wide configuration file (defaults to {sysconfdir}/tigrc). Define to empty string to use built-in configuration.
TIG_LS_REMOTE Command for retrieving all repository references. The command should output data in the same format as git-ls-remote(1).
TIG_DIFF_OPTS The diff options to use in the diff view. The diff view uses git-show(1) for formatting and always passes --patch-with-stat. You may also set the diff-options setting in the configuration file.
TIG_TRACE Path for trace file where information about Git commands are logged.
TIG_SCRIPT Path to script that should be executed automatically on startup. If this environment variable is defined to the empty string, the script is read from stdin. The script is interpreted line-by-line and can contain prompt commands and key mappings.
TIG_NO_DISPLAY Open Tig without rendering anything to the terminal. This force Ncurses to write to /dev/null. The main use is for automated testing of Tig.
FILES
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
$XDG_CONFIG_HOME/tig/config, ~/.config/tig/config, ~/.tigrc The Tig user configuration file is loaded in the following way. If $XDG_CONFIG_HOME is set, read user configuration from $XDG_CONFIG_HOME/tig/config. If $XDG_CONFIG_HOME is empty or undefined, read user configuration from ~/.config/tig/config if it exists and fall back to ~/.tigrc if it does not exist. See tigrc(5) for examples.
/etc/tigrc System wide configuration file.
$GIT_DIR/config, ~/.gitconfig, /etc/gitconfig Git configuration files. Read on start-up with the help of git-config(1).
$XDG_DATA_HOME/tig/history, ~/.local/share/tig/history, ~/.tig_history When compiled with readline support, Tig writes a persistent command and search history. The location of the history file is determined in the following way. If $XDG_DATA_HOME is set and $XDG_DATA_HOME/tig/ exists, store history to $XDG_DATA_HOME/tig/history. If $XDG_DATA_HOME is empty or undefined, store history to ~/.local/share/tig/history if the directory ~/.local/share/tig/ exists, and fall back to ~/.tig_history if it does not exist.
BUGS
1 2
Please visit Tig’s home page[1] or main Git repository[2] for information about new releases and how to report bugs or feature request.
COPYRIGHT
1 2 3 4 5
Copyright (c) 2006-2014 Jonas Fonseca <jonas.fonseca@gmail.com[3]>
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
Tig is more than just a text-mode interface for Git. Here’s how it can enhance your daily workflow.
If you work with Git as your version control system, you’ve likely already resigned yourself to the fact that Git is a complicated beast. It is a fantastic tool, but it can be cumbersome to navigate Git repositories. That’s where a tool like Tig comes in.
Tig is an ncurses-based text-mode interface for git. It functions mainly as a Git repository browser, but can also assist in staging changes for commit at chunk level and act as a pager for output from various Git commands.
This basically means that Tig provides a text-based user interface you can run in your terminal. Tig makes it easy to browse your Git logs, but it can do much more than just bounce you around from your last commit to a previous one.
Many of the examples in this quick introduction to Tig have been poached directly from its excellent man page. I highly recommend reading it to learn more.
If you want to browse the latest commits in your branch, enter:
1
tig
That’s it. This three-character command will launch a browser where you can navigate the commits in your current branch. You can think of it as a wrapper around git log.
To navigate the output, you can use the Up and Down arrow keys to move from one commit to another. Pressing the Return/Enter key will open a vertical split with the contents of the chosen commit on the right-hand side. You can continue to browse up and down in your commit history on the left-hand side, and your changes will appear on the right. Use k and j to navigate up and down by line and - and the Space Bar to page up and down on the right-hand side. Use q to exit the right-hand pane.
Searching on tig output is simple as well. Use / to search forward and ? to search backward on both the left and right panes.
That’s enough to get you started navigating your commits. There are too many key bindings to cover here, but clicking h will display a Help menu where you can discover its navigation and command options. You can also use / and ? to search the Help menu. Use q to exit Help.
Browse revisions for a single file
Since Tig is a wrapper around git log, it conveniently accepts the same arguments that can be passed to git log. For instance, to browse the commit history for a single file, enter:
1
tig README.md
Compare this with the output of the Git command being wrapped to get a clearer view of how Tig enhances the output.
1
git log README.md
To include the patches in the raw Git output, you can add a -p option:
1
git log -p README.md
If you want to narrow the commits down to a specific date range, try something like this:
Sometimes you want to find out who made a change to a file and why. The command:
1
tig blame README.md
is essentially a wrapper around git blame. As you would expect, it allows you to see who the last person was to edit a given line, and it also allows you to navigate to the commit that introduced the line. This is somewhat like the :Gblame command Vim’s vim-fugitive plugin provides.
Browse your stash
If you’re like me, you may have a pile of edits in your stash. It’s easy to lose track of them. You can view the latest item in your stash via:
1
git stash show -p stash@{0}
You can find the second most recent item via:
1
git stash show -p stash@{1}
and so on. If you can recall these commands whenever you need them, you have a much sharper memory than I do.
As with the Git commands above, Tig makes it easy to enhance your Git output with a simple invocation:
1
tig stash
Try issuing this command in a repository with a populated stash. You’ll be able to browse and search your stash items, giving you a quick overview of everything you saved for a rainy day.
Browse your refs
A Git ref is the hash of something you have committed. This includes files as well as branches. Using the tig refs command allows you to browse all of your refs and drill down to specific commits.
1
tig refs
When you’re finished, use q to return to a previous menu.
Browse git status
If you want to view which files have been staged and which are untracked, use tig status, a wrapper around git status.
Browse git grep
You can use the grep command to search for expressions in text files. The command tig grep allows you to navigate the output of git grep. For example:
1
tig grep -i foo lib/Bar
will navigate the output of a case-insensitive search for foo in the lib/Bar directory.
Pipe output to Tig via STDIN
If you are piping a list of commit IDs to Tig, you must use the --stdin flag so that tig show reads from stdin. Otherwise, tig show launches without input (rendering an empty screen).
1
git rev-list --author=olaf HEAD | tig show --stdin
Add custom bindings
You can customize Tig with an rc file. Here’s how you can configure Tig to your liking, using the example of adding some helpful custom key bindings.
Create a file in your home directory called .tigrc. Open ~/.tigrc in your favorite editor and add:
1 2 3 4 5
# Apply the selected stash bind stash a !?git stash apply %(stash)
# Drop the selected stash item bind stash x !?git stash drop %(stash)
Run tig stash to browse your stash, as above. However, with these bindings in place, you can press a to apply an item from the stash to your repository and x to drop an item from the stash. Keep in mind that you’ll need to perform these commands when browsing the stash list. If you’re browsing a stash item, enter q to exit that view and press a or x to get the effect you want.
Wrapping up I hope this has been a helpful demonstration of how Tig can enhance your daily workflow. Tig can do even more powerful things (such as staging lines of code), but that’s outside the scope of this introductory article. There’s enough information here to make you dangerous, but there’s still more to explore.