I am creating a simple debugfs file inside /sys/kernel/debug/test/testFile using the following code:
pDebugfs = debugfs_create_dir(name, NULL);
if (!pDebugfs)
goto fail;
if (!debugfs_create_file("testFile", MODE_T, pDebugfs,
NULL, &debugfs_fops)) {
goto fail;
}
And now when I write to this file, open method will be called which has the definition:
static ssize_t debugfs_open(struct inode *inode, struct file *filp)
Now the pDebugfs which is of type dentry has a pointer to an inode called d_inode as defined here.
My question is what is the relationship between this inode pointer and the one called in open? Are they related? If yes, how? I tried to print the i_flags value in both the i_node definitions but they don't match, I assign i_flags in init and just check its value in open but they don't match.
In your code you have two dentry. One that create the directory in /sys/kernel/debug/
pDebugfs = debugfs_create_dir(name, NULL);
and, you are not storing it but it is there, one that create the file you open(2):
pDebugfs_file = debugfs_create_file("testFile", MODE_T, pDebugfs, NULL, &debugfs_fops)
The inode you see in debugfs_open is the one associated to the file
and not to the directory.
Related
I'm trying to understand how devicetrees work.
According to the kernel documentation, they are used, in arm architecture, in the following manner:
In the majority of cases, the machine identity is irrelevant, and the kernel will instead select setup code based on the machine’s core CPU or SoC. On ARM for example, setup_arch() in arch/arm/kernel/setup.c will call setup_machine_fdt() in arch/arm/kernel/devtree.c which searches through the machine_desc table and selects the machine_desc which best matches the device tree data. It determines the best match by looking at the ‘compatible’ property in the root device tree node, and comparing it with the dt_compat list in struct machine_desc (which is defined in arch/arm/include/asm/mach/arch.h if you’re curious).
The ‘compatible’ property contains a sorted list of strings starting with the exact name of the machine, followed by an optional list of boards it is compatible with sorted from most compatible to least.
I found the source code related to the comparison of machine_desc to the compatible parameter set in the dts file:
const struct machine_desc * __init setup_machine_fdt(void *dt_virt)
{
const struct machine_desc *mdesc, *mdesc_best = NULL;
#if defined(CONFIG_ARCH_MULTIPLATFORM) || defined(CONFIG_ARM_SINGLE_ARMV7M)
DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
.l2c_aux_val = 0x0,
.l2c_aux_mask = ~0x0,
MACHINE_END
mdesc_best = &__mach_desc_GENERIC_DT;
#endif
if (!dt_virt || !early_init_dt_verify(dt_virt))
return NULL;
mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
if (!mdesc) {
const char *prop;
int size;
unsigned long dt_root;
early_print("\nError: unrecognized/unsupported "
"device tree compatible list:\n[ ");
dt_root = of_get_flat_dt_root();
prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
while (size > 0) {
early_print("'%s' ", prop);
size -= strlen(prop) + 1;
prop += strlen(prop) + 1;
}
early_print("]\n\n");
dump_machine_table(); /* does not return */
}
/* We really don't want to do this, but sometimes firmware provides buggy data */
if (mdesc->dt_fixup)
mdesc->dt_fixup();
early_init_dt_scan_nodes();
/* Change machine number to match the mdesc we're using */
__machine_arch_type = mdesc->nr;
return mdesc;
}
However, I didn't find machine_desc table definition.
If I'd like to read all machine_desc, Where can I find it?
TL;DR - The machine description is built by building and linking different source files into the kernel. So each machine source file adds an entry into the table.
The table is based in arch/arm/kernel/vmlinux.lds.S (or relevant architecture linker file). It is built with the macros MACHINE_START and MACHINE_END. This places a structure in the 'arch.info.init' sections of the object file. All of these objects get globbed together by the linker. This forms the table. So, it is constructed by linking different source files with the MACHINE_START and MACHINE_END macros. Therefore, it doesn't exist in one place.
However, you can use git grep -A10 MACHINE_START to get a fairly good list. This command works well, as typically, it is the last thing in the file so only five or six lines may print. Or you could write init code to dump the table by printing the machine_desc entries.
That said, the table is not too interesting as it is just function pointers to call at different times. The majority will be NULL as it used designated initializers.
Related: Control to 'dt_machine_start' on Android
Poking around I was unable to discover a way to detect hidden files in OS X with node (nodejs).
Of course, we can easily find the ".dot_hidden" files, but on the Mac, there are files/folders that are "protected" system files, that most users shouldn't fiddle with. In the Finder GUI, they are invisible or grey'd out when hidden files are forced to be shown via "AppleShowAllFiles".
I did discover a reference to UF_HIDDEN : 0x8000 here:
https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemDetails/FileSystemDetails.html
Using node's stat, we can return 2 additional bits of info that may provide a clue for the hidden status:
mode: 33188, // File protection.
ino: 48064969, // File inode number. An inode is a file
system data structure that stores
information about a file.
I'm not really a hex / binary guy, but it looks like grabbing the stat's "ino" property we can apply 0x8000 and determine if the file is being hinted as hidden or not.
I didn't have any success with the 0x8000 mask on the mode, but did have some with ino.
Here's what I've got, checking the "ino" returns 0 or 1726, when it's 1726 the file seems to match as a hidden file in OS X.
var fs = require("fs");
var dir = "/";
var list = fs.readdirSync(dir);
list.forEach(function(f){
// easy dot hidden files
var hidden = (f.substr(0, 1) == ".") ? true : false;
var ino = 0;
var syspath = dir + "/" + f;
if( ! hidden ){
var stats = fs.statSync(syspath);
ino = parseInt( stats.ino & 0x8000, 8);
// ino yeilds 0 when hidden and 1726 when not?
if(ino || dotted){
hidden = true;
}
}
console.log(syspath, hidden, ino);
});
So my question is if I'm applying the 0x8000 mask properly on the ino value to yeild a proper result?
And how would one go about parsing the ino property get at all the other flags contained within it?
The inode number (stats.ino) is a number which uniquely identifies a file; it has nothing to do with the hidden status of the file. (Indeed, it's possible to set or clear the hidden flag on a file at any time, and this won't change the inode number.)
The hidden flag is part of the st_flags field in the struct stat structure. Unfortunately, it doesn't look like the node.js fs module exposes this value, so you may need to shell out to the stat shell utility if you need to get this information on Mac OS X. (Short version: stat -f%f file will print a file's flags, represented in decimal.)
hello every one i want to ask you if you know a way to extract data from message_t
in the oldest version of TinyOs there are TOS_Msg and TOS_MsgPtr but in message_t i could't find a way please help me
and i want to know if there is any data type to store data like table or array list
typedef nx_struct message_localization{
nx_uint8_t NodeId;
bool ancre_nature;
nx_uint8_t x_coordinate;
nx_uint8_t y_coordinate;
x_uint8_t energie_transmited;
} message_localization_t;
The Packet interface has a command getPayload which does want you want:
command void *getPayload(message_t *msg, uint8_t len);
See the documentation for more information.
To access the data field, you may do as follows:
message_t msg;
message_localization_t *payload =
(message_localization_t *)call Packet.getPayload(
&msg, sizeof(message_localization_t));
payload->x_coordinate = x;
payload->y_coordinate = y;
/* and so on */
The same command is for convenience included in interfaces Send and AMSend. Packet and AMSend are provided by the ActiveMessageC configuration.
I have these two header files in the following path:
...\xfs\XFS_WINCOR_03\INCLUDE_03_00\xfsbcr.hpp
...\xfs\XFS_WINCOR_03\INCLUDE_03_10\xfsbcr.hpp
Both of them have structures called wfs_bcr_status.
This structure is different in each header file but have the same name.
INCLUDE_03_00\xfsbcr.hpp
typedef struct wfs_bcr_status
{
WORD fwDevice;
WORD fwBCRScanner;
DWORD dwGuidLights[WFS_BCR_GUIDLIGHTS_SIZE];
LPSTR lpszExtra;
} WFSBCRSTATUS, * LPWFSBCRSTATUS;
/////////////////////////////////////////////////////////////////////////
INCLUDE_03_10\xfsbcr.hpp
typedef struct wfs_bcr_status
{
WORD fwDevice;
WORD fwBCRScanner;
DWORD dwGuidLights[WFS_BCR_GUIDLIGHTS_SIZE];
LPSTR lpszExtra;
WORD wDevicePosition;
USHORT usPowerSaveRecoveryTime;
} WFSBCRSTATUS, * LPWFSBCRSTATUS;
In my code I have a cdm_device class that is derived from the device class.
In device I include the first header and I use the structure in my methods.
#include "INCLUDE_03_00/xfsbcr.h"
In cdm_device i include the second header.
#include "INCLUDE_03_00/xfsbcr.h"
In my methods, when I want to get wDevicePosition and usPowerSaveRecoveryTime, I get an error because it's not recognizing the second header file (03_10) and look into the first header file (03_00) and they are not define there.
How can I fix this?
Suppose I want to invoke some command on all files in a directory and set a watch to invoke that command on all files that get created in that directory. If I do:
while( ( sdi = readdir( d )) != NULL ) { ... }
closedir( d );
/* Files created here will be missed */
inotify_add_watch( ... );
then some files will potentially be missed. If I call inotify_add_watch()
before the readdir(), files may be acted on twice (it would require
a fair bit of infrastructure to prevent acting twice, and it seems that
the edge cases would be difficult to handle). Is there a simple way to avoid
having to record the names of all files worked on during the readdir loop and
comparing those to the names returned in the inotify_event structure? I can
minimize the amount of necessary comparisons with:
while( ( sdi = readdir( d )) != NULL ) { ... }
inotify_add_watch( ... );
while( ( sdi = readdir( d )) != NULL ) { /* record name */ ... }
closedir( d );
And usually the second readdir() loop will do nothing, but this feels like a bad hack.
You simply can't. The more you hack, the more race conditions you'll get.
The simplest actually working solution is to set the watch before using opendir(), and keep a list (set) of already used names (or their hashes).
But this isn't perfect either. User can have the file open in a text editor; you fix it, user saves it and the directory contains unfixed file anyway, though it's on your list.
The best method would be to be able for the program to actually distinguish used files by their content. In other words, you set watch, call command on readdir() results, then call it on inotify results and let the command itself know whether the file is fine already or not.