As an example: on my system (Ubuntu 10.04), the sockaddr structure is defined in /bits/sockaddr.h as
struct sockaddr{
_SOCKADDR_COMMON (sa_); /*...*/
char sa_data[14]; /*...*/
};
and similarly for sockaddr_in, with first field name sin_.
However, all the examples I see access the field sin_
structure_name.sin_family
I meant to track down the typedef (?) for completeness, followed included headers and such, but failed (I got to sa_family_t and similar).
As a more general question: is there, say, a searchable online source where you can simply search for where a macro or typedef is in the header files - either for a particular Ubuntu distribution, or more generically for 'typical' Linux installations? Or, obviously, a clever way from within Ubuntu's shell; or some description of how to be more efficient doing this any other idea.
This is the link:
LXR / The Linux Cross Reference
done...i'll get you the reference for the Linux Kernel API Browser later (used to be able to find it online somewhere). There's the Linux Kernel Archives for the actual source code, which you probably could generate documentation from anyways.
Sorry, but I've not come across something as beautiful as say, the
jQuery API Browser. Hopefully the 'Ubuntu Manpage' #
manpages.ubuntu.com/manpages/lucid/man7/netdevice.7.html, for example,
might suffice. Also for stuff like the struct sockaddr{, you might
like to check out the Linux Kernel API Browser (or something similar)
as that belongs to standard Linux networking protocol headers.
You could try: http://www.google.com/codesearch perhaps?
Related
I am writing a cross-platform (big 3 - Linux, MAC, Windows) backup program, so I need to know if a file has been edited since last time. My plan is to save the last save time in a file and check the real situation of a folder against the data in the file to determine which files need to be backed up or updated.
I would like to avoid methods that require a lot of processing power (like diff, or counting bytes).
In this similar post, people suggested to use fstat(), but that solution would be a last resort for me because I was hoping for a cross-platform solution that can be solved with pure C. As far as I know, fstat is a (2), and in my man page it appears as (1), which (to my understanding) means that it is a system function in Linux and isn't a part of the standard C library. I have searched for fstat on windows, but could only find some android version.
Is there some other way to access file metadata? Is there some other solution to this? I am open to any suggestions and am ok if it sometimes false-flags, as long as it backs up data correctly and doesn't waste resources on backing up everything all the time.
Please help!
Thank you!
fstat is still the way to do this, but on Windows it's called _fstat. You can check for the _MSC_VER macro which will be defined if you're building with MSVC, and if so create a macro alias for fstat.
You can do the same for struct stat which MSVC calls struct _stat:
#ifdef _MSC_VER
#define fstat(fd,buf) _fstat(fd,buf)
typedef struct _stat stat_struct;
#else
typedef struct stat stat_struct;
#endif
Then you can use fstat and pass it an argument of type stat_struct for the second argument.
I have a decently sized cross platform open source application that uses this technique.
My plan is to save the last save time in a file and check the real situation of a folder against the data in the file to determine which files need to be backed up or updated.
Ok.
I was hoping for a cross-platform solution that can be solved with pure C.
If by "pure C" you mean relying on only language features and library functions defined by the C language specification, then I'm afraid you're out of luck. Pure C (in that sense) has no concept of persistent file metadata such as modification timestamps. All functions and data structures dealing with such things are extensions or third-party libraries.
You can rely on standard POSIX facilities (such as fstat()) for both Linux and Mac, but Windows does not provide that. At least, Windows does not provide it exactly. The Microsoft C library does provide some POSIX compatibility functions, but it somewhat maddeningly uses modified names for them. In particular, it offers several flavors of _fstat() (note leading underscore). With a little bit of macro glue, it should not be too hard to make your program use POSIX fstat() on Linux and Mac, and use one of the _fstat() flavors on Windows.
As far as I know, ioctl() is used to expose an "extended" system call interface to userspace applications. Rather than adding thousands of system calls that are unique to specific drivers, ioctl() is used to provide extensible driver-specific functions through a single system call.
This seems clear enough. However, I'm trying to compile my first application that uses an ioctl() call, and I'm starting to doubt my understanding.
Specifically, I want to make an ioctl() call to "sanitize" an eMMC device. Taking a look at /usr/include/linux/mmc/ioctl.h (or in kernel source at include/uapi/linux/mmc/ioctl.h), I can see this structure:
struct mmc_ioc_cmd {
// Most fields omitted
int write_flag;
__u32 opcode;
__u32 arg;
};
From userspace, I don't have any issues including this header and passing this structure into my ioctl() calls.
So this is what my final sanitize snippet looks like:
int sanitize(int fd)
{
struct mmc_ioc_cmd command;
memset(&command, 0, sizeof(command));
command.write_flag = 1;
command.opcode = MMC_SWITCH;
command.arg = EXT_CSD_SANITIZE_START << 16;
return ioctl(fd, MMC_IOC_CMD, &command);
}
My problem is that MMC_SWITCH and EXT_CSD_SANITIZE_START are both defined in kernel headers. Specifically, in my kernel source, they're both found at include/linux/mmc/mmc.h.
Everything I've seen on the internet says to not include headers from the kernel source when building userspace projects. If that's the case, how can you reasonably use the MMC ioctl()? The kernel exposes the structure to pass into ioctl(), but it seems like you can only use the structure by filling it in with "hidden" constants hidden in the kernel source.
My current solution is to copy the necessary constants from the kernel headers to my own project, but this feels dirty to me.
Am I misunderstanding the use-case for ioctl()? Is this a design oversight?
The MMC_IOC_CMD ioctl, and the corresponding mmc_ioc_cmd structure, are part of the Linux userspace API, and therefore are defined in the uapi headers that are installed into /usr/include.
The value that you put into the opcode field gets sent directly to the device. The kernel does not really care what it is, and cannot guarantee what opcodes the device supports, or how it behaves for any specific opcode. Therefore, opcodes like MMC_SWITCH are not part of the API.
As far as I can see, you are supposed to get the opcodes from the relevant MMC standards.
(This is not really a good reason to keep these symbols out of the user-space API; copying the kernel header is much easier than manually transcribing the values from the standard. And the kernel actually has a special case for handling EXT_CSD_SANITIZE_START through this ioctl.)
If you can #include it without adding any additional -I include paths on your GCC command line, then you're fine.
Everything I've seen on the internet says to not include headers from the kernel source when building userspace projects.
That advice means don't include headers directly from the kernel source tree. The uapi headers are intended to be consumed from userspace, and are installed into /usr/include.
On line 63 of this example header file there is a typedef:
typedef struct _snd_ctl_elem_info snd_ctl_elem_info_t;
There are multiple examples of typedefs like that through the code.
My goal is to get to the actual definition of the structure _snd_ctl_elem_info but I have grepped the source and googled but found no traces of the actual definition. Because of this search failure, I've started to think I might be missing some concepts and it might be something to do with kernel and backwards compatibility?
My motivation for this is to be able to gdb step through alsa and have an overview of the structures.
Is this some form of a low level structure definition pattern?
This structure is also used by alsa-lib to communicate with the kernel, so it just reuses the kernel's definition.
The kernel header would be installed as /usr/include/sound/asound.h, but to avoid a dependence on the kernel headers being installed correctly, alsa-lib has its own copy of this file in alsa-lib/include/sound/asound.h.
Applications are not supposed to access the members of this structure directly, so alsa-lib does not include asound.h from its official headers (and does not even install it; it's used only when compiling alsa-lib).
To get the actual definition, you would need #include <sound/asound.h>.
It sounds like it gets renamed from a typedef:
#define _snd_ctl_elem_info sndrv_ctl_elem_info
So you're looking for sndrv_ctl_elem_info, which is way easier to find.
It is defined in asound.h at line 809.
It's pretty massive so I won't paste it here.
It is defined in API header snd/asound.h. This is what client code is supposed to #include.
Section 2 of the Linux man pages contains system calls.
http://linux.die.net/man/2/
After finding this link, I say "OK! I use this reference for developing every modules, It is complete".
But it seems I can not use some functions of this section (like bind(2)). After including required headers (like <sys/socket.h>) the module compilation failed.
Some functions/macros like printk does not listed in the section 2. Many people used Linux Apis that I could not find any official reference for it (just like printk). I don't know how they found these functions? (May be by reading whole source code of kernel instead of reading any reference)
Some functions like memset describes in section 3 (user space libraries) but kernel module developer can use it without any error!
Where I can found a COMPLETE reference of available headers and functions when developing a loadable kernel modules? (Something like MSDN and WINDDK references)
#include <linux/init.h>
#include <linux/module.h>
/* A complete list of availabe headers and functions is missing! */
static int my_init(void)
{
return 0;
}
static void my_exit(void)
{
return;
}
module_init(my_init);
module_exit(my_exit);
As you know, the Kernel is quite a big, big and independent beast. This means that you cannot include anything which is not found under your kernel source tree.
When you're implementing your module, that means the only things you can link to is what you got in :
The kernel source tree itself
Another module you've made (I would recommend to avoid this scenario though whenever possible ... )
Note that you will be able to use the functions only if they are exported. You can check this using the nm utility on the compiled .ko file of a module. If you want to export some symbols of your module, you have to use the macro EXPORT_SYMBOL.
Be careful not to confuse user-space includes, usually found under /usr/include with the kernel module headers (which you are likely wanting to link against).
In the example you gave, the sys/socket.h is the location of the header after a make headers_install. At this location, it is meant to be used by userspace applications. This is NOT what you want when you are programming a module.
I think you have to look deeper in the use of sockets in the kernel. By googling up a little, I found -> this <- on LWN and checked the include/linux/net.h header of my 3.8 kernel source tree. The patch described in the link is integrated in the kernel and is likely to be what you are looking for.
The memset example is also an illustration of what I explained this far : if you want to use it in a common application, you'll have to include the string.h header, which is simply located at /usr/include/string.h. Its kernel equivalent is found under ...
/your-kernel-source-tree-dir/include/linux/string.h
Et voila ! You can use memset and friends inside any piece of kernel code, as long as you include the right header !
Thus, when you feel some frustration, thinking Man, I was able to use this by simply including this header in my apps ... Take a deep look at the kernel source tree (or have grep do it for you ;) ). You are very likely to find what you are looking for !
As per my knowledge there is no such complete reference for kernel module programming. I suggest you study the LDD3 basic sections and http://www.tldp.org/LDP/lkmpg/2.6/html/lkmpg.html#AEN978 for a beginner.
I write or modify programs which perform name resolution and need a
good control of the process. So I do not use getaddrinfo(), I go
deeper and use res_query() / res_send() / etc in resolv.h, documented
in resolver(3).
Although not documented, the common way to set the resolver used is to
update _res.nsaddr_list. But this array, defined in resolv.h, stores
struct sockaddr_in, that is IPv4 addresses only. (IPv6 addresses
are struct sockaddr_in6, a family-independant system would use struct sockaddr.)
I'm looking for a way (preferrably portable, at least among the
various Unix) to tell _res that I want also IPv6 addresses.
Apparently, a long time ago, there was in FreeBSD a _res_ext with this
ability but I cannot find it anymore in a recent FreeBSD 7 (grep
_res_ext /usr/include/resolv.h finds nothing). You can still find
code which uses it (try yourself with Google Codesearch).
Thanks to Alnitak, I noticed it is apparently now _res._ext and not .res_ext. I wonder where these sort of things are documented or announced... I have no idea how portable _res._ext is. I can find it on Debian and FreeBSD. It seems there are few programs which use it.
Stéphane - if your resolv.h doesn't include any support for sockaddr_in6 then that suggests that on your particular O/S the resolver does not itself support IPv6 transport.
I've checked some of my systems here:
MacOS X 10.5.6 - supports the BIND 9 library, which has a res_setservers() function which can take IPv6 addresses, no _res._ext extension.
CentOS 5.2 - has the _res._ext extension, although there's no mention of IPv6 in the man page for resolv.conf except that there's a setting to tell the resolver to return AAAA records before looking for A records for gethostbyname().
EDIT - also, the CVS repository for FreeBSD suggests that FreeBSD 7.0 (see tag FREEBSD_7_0_0_RELEASE) does also support res_setservers() from Bind 9.
glibc:
res_setservers: no
__res_state._u._ext.nsaddrs
__res_state._u._ext.nsmap
set the latter to MAXNS+1 according to:
http://sourceware.org/ml/libc-hacker/2002-05/msg00035.html
BSD-libc:
res_setservers: yes
__res_state._u._ext.__res_state_ext
Seems messy to me and you'll probably need autoconf.